16 Filling out a manifest

 

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.

16.1 Module execution order

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.

Within a module folder, PowerShell looks for the following:

  1. 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.
  2. A .dll file with the same filename as the module’s folder name. This is a compiled or binary module, usually written in C#.
  3. 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.

First, the module can’t easily handle things such as versioning, establishing prerequisites, and loading supporting files (e.g., custom formatting views, which we’ll get to later in this book). As your modules become more complex and you iterate them over time, you’ll need them all.

16.2 Creating a new manifest

16.3 Examining the manifest

16.3.1 Metadata

16.3.2 The root module

16.3.3 Prerequisites

16.3.4 Scripts, types, and formats

16.3.5 Exporting members

16.4 Your turn

Summary