A PowerShell module packages reusable commands, functions, variables, and supporting resources. A script module uses a .psm1 file, turning focused functions into commands that PowerShell can discover and load on demand. section 10.2 section 10.6
Build a practical script module by following these steps:
- Keep functions tightly scoped and self-contained; accept declared parameters and write useful objects to the pipeline. section 10.6
- Create a module folder and a matching .psm1 filename beneath a directory listed in $env:PSModulePath. section 10.2 section 16.1
- Import the module when testing, then unload or reload it after edits because PowerShell runs the loaded version from memory. section 10.4
- Add a .psd1 manifest as complexity grows; specify the root module, prerequisites, version, metadata, and explicitly exported members. section 16.1 section 16.2
- Export only public functions, variables, and aliases, leaving helper functions private; avoid wildcard exports when load performance matters. section 16.3.5
A module that grows with the tool
A MolTools script module can expose Set-TMServiceLogon with service, password, username, and computer-name parameters. Test it against BITS on the local host or several servers, then unload and reload the module after changes. A larger module can keep a database connection string and a table-creation function private while exporting Get-DiskInfo. section 10.5.2 section 26.3
Get-MachineInfo -ComputerName localhost
Use the Get-MachineInfo command to verify that PowerShell discovers the module and exposes its function as a command. section 10.4
Modules can remain local reusable tools or become shared packages. Before publishing, search the PowerShell Gallery for competing functionality; when revising a published module, update its manifest version so users can retrieve it with Update-Module. section 22.4.1 section 22.5.1
