As I previously mentioned a little over a month ago in my blog article PowerShell Script Module Design Philosophy, I’m transitioning my module build process to a non-monolithic design in development and a monolithic design for production to take advantage of the best of both worlds. Be sure to read the previously referenced blog article for more details on the subject. My goal is to write a reusable tool to retrieve the necessary information from a non-monolithic script module that’s necessary to create a monolithic version of the same module.
PowerShell Script Module Design
This week, I’ll continue where I left off in my previous blog article PowerShell Script Module Design Philosophy. Moving forward, the development versions of my PowerShell script modules will use a non-monolithic design where each function is dot-sourced from the PSM1 file. When I move them to production, I’ll convert them to using a monolithic design where all functions reside in the PSM1 file. In development, each PS1 file uses a Requires statement which specifies the requirements from a PowerShell version and required modules standpoint.
Years ago, when I first learned how to create PowerShell script modules, I built them with all the functions in one huge monolithic PSM1 file. I like the monolithic script module design from a performance and security standpoint along with the ease of signing fewer files if you’re taking advantage of code signing to digitally sign your scripts and modules (there are fewer files to sign). What I don’t like is that collaborating with others using one huge file is a merge conflict waiting for a place to happen and if someone only wants one of my functions instead of the entire module, they’re out of luck unless they want to copy and paste it.
Using asterisks (*) in your module manifest is a bad idea no matter how you look at it. First, your module will be slower because it will have to figure out what to export. More importantly, if you use a “#Requires -Modules” statement in your functions and they’re in separate PS1 files, all of the specified module’s commands will show as being part of your module. I’ll pick up where I left off in one of my previous blog articles PowerShell Script Module Design: Plaster Template for Creating Modules.
I recently began updating my PowerShell script module build process. Updating my Plaster template was one of the first things I needed to do. If you haven’t already read my blog article about Using Plaster to create a PowerShell Script Module template, I’d recommend beginning there as this blog article assumes you already have a basic understanding of how to use Plaster. All of the information from my previous Plaster template is still there with the exception of the required PowerShell version as I plan to obtain that information and update it a different way.
There’s been a lot of debate about script module design as of lately and instead of tweeting something out asking for responses, I thought I would post it here via a blog article. Back when I first started creating PowerShell script modules, I placed all of my functions in the PSM1 file and later started placing each function in a separate PS1 file that was dot-sourced from the PSM1 file.