What are generally regarded the best practices for PowerShell module structure. I have been scouring the internet for answers and cannot find a definitive article.
I currently use the folder structure described here : https://xainey.github.io/2017/powershell-module-pipeline/#add-private-and-public-folders . This works well for me. I recently stumbled upon https://github.com/PoshCode/ModuleBuilder . I could not find any examples of it’s use, but reading through the doc it seems to elude to the idea of developing a module where each function is a file (which I already do) and then when you release it to “prod” it is compiled as a single psm1 file ? This module talks about best practices but there is no substantiating evidence of what these best practices are, and why they are regarded as best practices. Is there a guide to good powershell module best practices.
It all depends, since PowerShell is a scripting language we can’t define a best way to achieve something, there is always a better way. In many places instead of modules each function is written in .ps1 file and sourcing them as & when it is needed. Even in my opinion instead of loading the entire module once, you can load the functions whatever is required. This is my idea, but there must be another better approach.
Hard to say if there’s a definitive “best practice” across the board, it all depends on your development and release processes and how you want it to work. In general, I’d say keeping public/private/etc folders is a good idea, helps keep things nice and tidy so you can work on things more easily.
Whether you want to compile it to a single PSM1 for release is up to you. Normally, there will not be a noticeable difference until you have at least several hundred commands in your module. However, if you’re signing your script file(s) I’d recommend compiling a single PSM1 and then signing just that. If PS has to process a couple dozen signatures, you’re gonna have some VERY slow module loading times. If it’s one signature on a big file, it won’t even be noticed.
Somewhere back in the beginning of this forum (or maybe even in the previous version), Don Jones started a thread about Powershell best practices, and it may have some community recommendations about modules. I really thought that it lead to an ebook, but I don’t see it now. Might be worth digging up, though…
While some things are “Best Practices”, such as having proper headers and comment, others are really just personal preference, such as how to capitalise your variables: $VariableCase/$variableCase/$variablecase
When a colleague and I was tasked with standardising our PowerShell development and coming up with standards we stolecame up with a few:
– Start your scripts with a standard set of comments (name, date, author, purpose and keywords) to easily find them later.
– Add comments as much as possible.
– Use simple but meaningful variable names. PascalCase is our current best practice. (e.g. $ServiceName or $CounterName, and not $s, $c or $servicename).
– Place user-defined variables at the top of script. It makes it easier for you or anyone making changes to those script variables.
– Don’t use aliases in scripts. Ever! Use the full cmdlet name with its named parameters.