Need help with ModuleBuilder?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

283 Stars 45 Forks MIT License 269 Commits 7 Opened issues


A PowerShell Module to help scripters write, version, sign, package, and publish.

Services available


Need anything else?

Contributors list

The Module Builder Project

This project is an attempt by a group of PowerShell MVPs and module authors to:

  1. Build a common set of tools for module authoring
  2. Encourage a common pattern for organizing PowerShell module projects
  3. Promote best practices for authoring functions and modules

In short, we want to make it easier for people to write great code and produce great modules.

In service of this goal, we intend to produce:

  1. Guidance on using the best of the existing tools: dotnet, Pester, PSDepends, etc.
  2. Module templates demonstrating best practices for organization
  3. Function templates demonstrating best practices for common parameters and error handling
  4. ModuleBuilder module - a set of tools for building modules following these best practices

The ModuleBuilder module

This module is the first concrete step in the project (although it currently consists of only two commands). It represents the collaboration of several MVPs and module authors who had each written their own version of these tools for themselves, and have now decided to collaborate on creating a shared toolset. We are each using the patterns and tools that are represented here, and are committed to helping others to succeed at doing so.

Building from source

Build Status

1. Get the source, obviously

git clone
cd Modulebuilder

2. Install dependencies

We have a few modules which are required for building. They're listed in

-- the
script installs them (it defaults to CurrentUser scope, but has a
parameter if you're running elevated and want to install them for the
). They only change rarely, so you shouldn't need to run this repeatedly, but it does import the modules too, so if you need to use newer versions of these modules (like Pester 5), you can use this to import the ones we need:

3. Run the

By default, the build script uses gitversion to calculate the version of the build automatically, and will put the build in a folder like "ModuleBuilder\2.0.0" where 2.0.0 is the current version number.


If you don't have

handy, you can just specify a version for the
./build.ps1 -Semver 2.1.0-beta

4. Run tests with Pester


script runs Pester and ScriptAnalyzer. It finds the build output from our
script in the default build output location -- that is, right next to these scripts in the root of the repository. It actually removes the
module and re-imports the highest version in that root:

If you want to test against a different version, you can import it manually and

You have a lot of other options here ...

You could import the module explicitly from the output path:

./build.ps1 | Split-Path | Import-Module -Force

You could build into your personal Modules directory, instead:

./build -Output ($Profile | Split-Path | Join-Path -ChildPath Modules)

What's in the module, so far:


Builds a script module from a source project containing one file per function in



command is a build task for PowerShell script modules that supports incremental builds.


Takes the output from

Invoke-Pester -Passthru
run against the build output, and converts the code coverage report to the source lines.

A note on build tools

There are several PowerShell build frameworks available. The build task in ModuleBuilder doesn't particularly endorse or interoperate with any of them, but it does accomplish a particular task that is needed by all of them.

A good build framework needs to support incremental builds and have a way to define build targets which have dependencies on other targets, such that it can infer the target build order.

A good build framework should also include pre-defined tasks for most common build targets, including restoring dependencies, cleaning old output, building and assembling a module from source, testing that module, and publishing the module for public consumption. Our

command, for instance, is just one task of several which would be needed for a build target for a PowerShell script module.

Organizing Your Module

For best results, you need to organize your module project similarly to how this project is organized. It doesn't have to be exact, because nearly all of our conventions can be overriden, but the module is opinionated, so if you follow the conventions, it should feel wonderfully automatic.

  1. Create a
    folder with a
    file and your module manifest in it
  2. In the
    specify the relative Path to your module's manifest, e.g.
    @{ Path = "ModuleBuilder.psd1" }
  3. In your manifest, make sure a few values are not commented out. You can leave them empty, because they'll be overwritten:
    • FunctionsToExport
      will be updated with the file names that match the
    • AliasesToExport
      will be updated with the values from
      attributes on commands
    • Prerelease
      in the
      hashtable in

Once you start working on the module, you'll create sub-folders in source, and put script files in them with only one function in each file. You should name the files with the same name as the function that's in them -- especially in the public folder, where we use the file name (without the extension) to determine the exported functions.

  1. By convention, use folders named "Classes" (and/or "Enum"), "Private", and "Public"
  2. By convention, the functions in "Public" will be exported from the module (you can override the
  3. To force classes to be in a certain order, you can prefix their file names with numbers, like

There are a lot of conventions in

, expressed as default values for its parameters. These defaults are documented in the help for Build-Module. You can override any parameter to
by passing it, or by adding keys to the
file with your preferences.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.