Module hell is a confusing, frustrating, and twisted place filled with poorly documented modules, non-compliant team mavericks, untested scripts, and hyper-niche (basically single-use) PowerShell modules.

The good news is, all you need to climb out of (or avoid) module hell is the right tool and a little bit of know-how.

Before we dive into climbing out, it’s important to understand how you got there. Or else you’re destined to repeat history and take the same road back.

Script hell

Script Hell is the Wild West, it’s anarchy. It’s where team members create complicated, personal scripts for company use, cliques build information silos, and where no one documents changes applied to edited scripts. Script hell is really just a description of an organization with bad scripting practices. Without tools and training, most teams naturally end up here without even knowing how it happened.

The danger with script hell is the longer you stay, the more brittle and unmanageable your scripts get. It also means that your team is much more likely to get accustomed to these practices, making things much more difficult to change and fix as time goes on.

How Modules Can Help You Climb Out of Script Hell

PowerShell modules (.psm1 files) allow you to combine like scripts into a single, cohesive package that can be shared between users. Users can import your modules/packages into their PowerShell environment to add functionality. Modules aren’t directly run in the PowerShell; instead, they become a part of it. For example, the Azure module allows PowerShell to manage Microsoft Azure service. Think of it like installing a new Wi-Fi adapter in a computer: As soon as the adapter is installed, the computer will have Wi-Fi functionality added.

However, simply using modules does not guarantee you a one-way ticket out of script hell. Without first assessing how you got to script hell in the first place, your PowerShell modules risk pulling you even deeper into module hell.

Module Hell & Why it’s Worse

Module hell is a fun-house mirror image of script hell. Really, it’s just describing an organization that’s gone from bad scripting practices to bad module practices, which by the way is much worse.

What makes module hell so dangerous is that these modules are now intertwined and a part of the (your) PowerShell. The risk of catastrophic failure (server downtime, security failure, license breach, etc.) is exponentially increased.

Catastrophic Failures

Modules Made by You/Your Company (First-Party Modules)

Your first-party modules are incredibly valuable assets, too valuable to be shared with the world on third-party, public, repositories. Unfortunately, without your own private repository, first-party PowerShell modules need to be posted to PowerShellGallery.com and are NOT private.

 However, not hosting on a third-party site means your modules aren’t easily accessible for internal use. This creates bottlenecks and is just frustrating for developers. Also, production-ready and unready modules are NOT clearly separated. Meaning it’s not clear which modules are validated and should be used.  

Modules You Downloaded from PowerShellGallery or Other Places (Third Party Modules )

Without tasking a team member to check for module quality, it’s difficult to know what vulnerabilities or dependencies any third-party module has. This could lead to serious failures (data breach, security exploitation, etc.) However, tasking developers to quality-check every single package and module before it’s used isn’t exactly an attractive solution.

How to Get Out of Module Hell?

All you need to climb out of module hell is the right tool and a little know-how.

Using a tool like ProGet that enables and enforces DevOps best practices greatly increases your chances of escaping module hell. ProGet also eliminates some of the risks of first-party and third-party catastrophic module failure.

Using PowerShell modules with ProGet keeps first-party PowerShell both private and easily accessible for internal use. ProGet can also enforce access rules on top of separating modules by quality in different feeds. Feed-level privilege controls in ProGet give granular control over per-feed permissions and are made even easier by integrating with AD/LDAP to use existing teams and roles.

License detection and blocking offer additional peace of mind to avoid the liability and litigation of licenses like GPL-3. License detection and blocking in ProGet read package metadata to alert you of licenses present. Then you can configure ProGet to block (or allow) certain license types, keeping unwanted licenses far away from production.

Finally, as a little bonus, PowerShell can help prevent future catastrophes by creating a GUI around your PowerShell scripts. This reduces the risk of a script accidentally being run on an incorrect server. 

Next Steps to Climb Out of Module Hell

Module hell is a scary and dangerous place to be. The longer your modules stay there, the more of a liability they become. And the longer your team stays there the more comfortable they’ll get. 

Using a tool like ProGet as a private repository for your first-party modules and scanning third-party modules is the first step in climbing your way out. But that’s not the only thing you can do! Tune up your PowerShell knowledge and know-how and prepare yourself and your team for any heat that may come your way.

Are you ready to “Level Up” your PowerShell usage? For many more ways to give your PowerShell scripts and modules a boost, take a look at our free eBook, “Ultimate Powershell Levelup Guide”. Sign up for your copy today!