Libraries#
PowerShell’s re-use story has three layers. Built-in cmdlets
ship with the core modules and require no setup. Modules are
the unit of distribution; folders with a .psd1 manifest and
.psm1 script that Import-Module loads. The PowerShell
Gallery is the public registry; Install-Module pulls from
it. On top, the operator can .-source plain script files
into the current scope.
Built-in Helpers#
The core modules cover the bread-and-butter operations.
Module |
What it brings |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
Interactive line editor (always loaded in interactive sessions) |
|
|
Cmdlet Quick Reference#
The cmdlets most operators reach for outside the obvious ones.
Cmdlet |
Use it for |
|---|---|
|
JSON ↔ object |
|
CSV ↔ object |
|
HTTP API call returning a parsed object |
|
HTTP call returning the raw response |
|
Run a script block locally or on remote hosts |
|
Background work |
|
Random number / element |
|
Build a TimeSpan for arithmetic with dates |
|
Force formatting, write to file, discard |
|
Save pipeline output to a file and pass it on |
PowerShell Gallery#
The PowerShell Gallery (gallery) hosts community and
vendor modules. The operator manages installs through PowerShellGet.
Find-Module -Name Pester # search
Install-Module -Name Pester -Scope CurrentUser # install
Update-Module -Name Pester # upgrade
Uninstall-Module -Name Pester
Get-InstalledModule # what's installed
Save-Module -Name Az.Compute -Path ./vendor # vendor (no install)
Module scopes.
-Scope CurrentUser, the user-local install (~/.local/share/powershell/Moduleson Linux,$HOME\Documents\PowerShell\Moduleson Windows).-Scope AllUsers, the system-wide install, needs admin.
Common Modules#
The third-party modules the everyday operator pulls in.
Az, the Azure cmdlet suite. Big; the operator usually imports only the sub-modules they need (
Az.Compute,Az.Storage).AWS.Tools.*, modular AWS cmdlets; one module per service.
Microsoft.Graph, Microsoft 365 / Entra ID / Intune over Graph API.
Pester, testing framework.
PSScriptAnalyzer, linter.
PSReadLine, line editor.
ImportExcel, read / write
.xlsxwithout Excel installed.PSFramework, logging, config, runspace pools.
Building a Module#
A module is a folder.
MyModule/
MyModule.psd1 # manifest (metadata)
MyModule.psm1 # main script (entry point)
Public/ # one .ps1 per public function
Get-Thing.ps1
Private/ # internal helpers
Helper.ps1
The .psm1 typically dot-sources every .ps1 under
Public and Private and exports the public names.
# MyModule.psm1
$public = @( Get-ChildItem $PSScriptRoot/Public/*.ps1 -ErrorAction SilentlyContinue )
$private = @( Get-ChildItem $PSScriptRoot/Private/*.ps1 -ErrorAction SilentlyContinue )
foreach ($file in $public + $private) {
. $file.FullName
}
Export-ModuleMember -Function $public.BaseName
Generate a manifest.
New-ModuleManifest -Path ./MyModule.psd1 `
-RootModule MyModule.psm1 `
-ModuleVersion 0.1.0 `
-Author 'operator' `
-FunctionsToExport 'Get-Thing'
Publish.
Publish-Module -Path ./MyModule -NuGetApiKey $env:PSGALLERY_KEY
Dot-Sourcing a Script#
For ad-hoc re-use without packaging, dot-source a script into the current scope. Every function and variable it defines is available afterwards.
. ./helpers.ps1
Get-MyHelper
The single leading dot is significant; without it, the script runs in its own scope and the names vanish on return.
References#
Get-Help about_Modules,Get-Help about_Module_Manifests,Get-Help about_Scopes.Frameworks for testing, linting, and the patterns module-builders reach for.
Overview for the language-level
Import-Module/.-sourcing discussion.