Up to this point, you’ve been relying on the PowerShell magic to make your commands—within a module—run. It’s worth digging into this magic a bit because you can do much more with it.
When PowerShell looks for modules, it first enumerates all the folders listed in the PSModulePath environment variable. Each folder under each of those paths is considered a potential module.
- A .psd1 file with the same filename as the module’s folder name. This module manifest tells the shell what else needs to be loaded.
- A .dll file with the same filename as the module’s folder name. This is a compiled or binary module, usually written in C#.
- A .psm1 file with the same filename as the module’s folder name. This is a script module.
You’ve been using number 3 on that list. If you create a file named \Documents\ PowerShell\Modules\MyPSModule\MyPSModule.psm1, then you’ve created a script module named “MyPSModule,” and whatever functions are in that .psm1 file will become commands that PowerShell can run. This is a super quick and easy way to get a module up and running, but it has some disadvantages.