PowerShell Module Development - Reuse and Maturity

In the last years, I learned to reuse some code between PowerShell modules, not like Cmdlets imported from other modules but structure and tools. I’ll explain how to improve your modules and your development process.

Tier 1 - Minimum PowerShell Module

A PowerShell module is only a manifest file like myModule.psd1 and a code file implementing it myModule.psm1. None of them allow much reuse since both are custom for every module.

Tier 2 - Structure, Instructions and Testing

If you maintain that module over a longer time range, you should invest more effort. Use a single file per Cmdlet to support analysis or change. Add a readme file with instructions and the general concept. Add Pester tests to minimize bugs. As a side effect, tests can be used as examples too. Most of that is still individual to that module. But you could automatically load the psd1 files per Cmdlet and publish them based on the directory structure.

Tier 3 - Build and Automation

If you implement the module in C# (binary module), before using and testing it, you need to build myModule.dll file. Therefore you should use InvokeBuild and VS Code tasks to simplify and automate it.

Tier 4 - Open Source and Sharing

If your project is open-source, users won’t know much about it. You should add documentation, instruction, and license information. Additionally, publish it to PowerShell Gallery. Documentation should be based on platyPs. The content is specific for your module, but the generation and export are not. The license may be the same for all your modules but won’t often change anyway. The publishing to PowerShell Gallery can be reused but needs configuration per module. Installation and contribution instructions should not deviate between your modules.

Tier 5 - Release Management and Continuous Integration

When your project becomes more mature, more people or projects depend on it - think about release management, branching models, and CI/CD. Therefore I recommend Semantic Versioning, keep a changelog and GitFlow. These are conventions, but you can develop your automation workflows for build validation, release, and pre-release.

Summary

Your module became quite complex, but you can simplify it by automation. You should understand all parts, but they won’t slow you down compared to the benefit. More, in my next post about streamlining the development.