On top of your well-defined module, there is still the module manifest. If you are serious about proper module development, you should spend time on the manifest, as well. Among the usual meta information, such as author, creation date, and description, the manifest contains a list of exported functions, required modules, version dependencies, .NET libraries, and more.

When publishing your module to a gallery, the manifest will be used to generate additional information that the package management system is able to use:

@{
# Script module or binary module file associated with this manifest.
RootModule = 'MyManifestModule.psm1'

# Version number of this module.
ModuleVersion = '0.0.1'

# Supported PSEditions
CompatiblePSEditions = @('Desktop','Core')

# ID used to uniquely identify this module
GUID = '559aebcd-7a68-4dde-9bcb-76f5f181a6fc'

# Author of this module
Author = 'JHP'

# Company or vendor of this module
CompanyName = 'Unknown'

# Copyright statement for this module
Copyright = '(c) JHP. All rights reserved.'

# Description of the functionality provided by this module
Description = 'Automates everything.'

# Minimum version of the PowerShell engine required by this module
PowerShellVersion = '5.1'

# Functions to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no functions to export.
FunctionsToExport = @('Get-MyData')
}

The preceding example contains the commonly used keys of a module manifest. At the very least, use this manifest to fill out the descriptions and maintain the exported functions, variables, and aliases. Loading a manifest module with a properly defined manifest will make the module auto-loading process faster.

Additionally, the manifest can be used to track all files belonging to a module with the key FileList. In the key ModuleList, you can add all modules that are shipped with your module. It is a valid approach to package your root module along with a couple of additional modules. When talking about a module release pipeline in Chapter 10, Creating Your Own PowerShell Repository, we will see that publishing each module on its own might be a better choice.

If you add required modules to your manifest, and you are using the PowerShell Gallery to publish it, the dependencies will be resolved, and the modules will automatically be downloaded, if possible.