PowerShell Module Design Rules (and When to Bend Them)
summary
Concrete rules and tradeoffs: package everything in a folder with a PSD1 manifest and a tiny PSM1 loader, or face versioning and PSModulePath failures (PowerShell stops at the first matching name). Ship binary builds for both .NET2 and .NET4 when needed. Use standard verbs, prefix nouns to avoid collisions, and strongly type parameters (null constructor for hashtable remoting). Favor pipeline binding and matching parameter names to object properties; heavy edge options go in separate objects (one command with ~20 parameter sets for rare cases).
AI-written summary · about
chapters (12)
- 0:00PowerShell module design intro
- 1:27Module anatomy
- 7:20Module files and folders
- 11:39Command naming rules
- 18:23Parameter design rules
- 26:31Parameter sets 80-20
- 29:21Pipeline binding design
- 36:44Wildcards and host features
- 38:10Demo: command structure
- 44:51Identity patterns in practice
- 49:37Public API design
- 51:01Binary module tips
related talks
45mBullet-proofing Patterns & Practices
22mIt's Raining Modules
47mTempting Fate: Patterns & practices for shareable scripts and functions
51mDon't do that, do this instead: PowerShell worst practices and..
45mPowerShell Module Mass Production: Templating in the Field
46mThese Are the Modules You’re Looking For: Packaging and Publishing PowerShell..
52mWrite Modules, Not Scripts
43mPowerShell Tooling