Summary
ModuleBuilder 3.2.0 (released 2026-05-11) introduces two regressions that block consumers that previously worked on v3.1.7 / v3.1.8:
- Windows PowerShell 5.1 cannot import the module at all — the built
ModuleBuilder.psm1 uses PowerShell 7-only syntax.
Build-Module now fails on PowerShell 7+ when the source manifest does not contain an uncommented AliasesToExport — this used to be optional.
Bug 1: Parse errors on Windows PowerShell 5.1
Import-Module ModuleBuilder fails before any user code runs:
At ...\ModuleBuilder\3.2.0\ModuleBuilder.psm1:1003 char:81
+ ... "Add-Parameter $($InputObject.Extent.File -ne "scriptblock" ? $InputO ...
Unexpected token '?' in expression or statement.
At ...\ModuleBuilder\3.2.0\ModuleBuilder.psm1:1858 char:9
+ | Where-Object { $_.OutputType.Name -eq "TextReplacement" -or ...
An empty pipe element is not allowed.
Root causes in the shipped .psm1:
- Line 1003: ternary operator
? : (PowerShell 7+ only)
- Line 1858: pipe-leading whitespace / multi-line pipeline starting with
| (PowerShell 7+ only)
This is a regression of the same class as #135 / fixed in #136 — PS 5.1 parse errors caused by newer-syntax constructs in code paths that PS 5.1 has to parse at module-load time.
Bug 2: AliasesToExport now mandatory on PowerShell 7+
Even where the module imports successfully (i.e. on PS 7), Build-Module now rejects source manifests that have AliasesToExport commented out:
Get-Metadata: Can't find 'AliasesToExport' in <source>\<Module>.psd1
The field was optional in v3.1.x. It is unclear from the changelog whether this is intentional (in which case it is a breaking change that should be documented and major-version-bumped) or an unintended side-effect.
Repro
Install-Module ModuleBuilder -RequiredVersion 3.2.0- On Windows PowerShell 5.1:
Import-Module ModuleBuilder → parse error.
- On PowerShell 7+ with any source manifest that has
# AliasesToExport = @() commented out: Build-Module → Get-Metadata error.
Environment
- ModuleBuilder: 3.2.0 (PSGallery, published 2026-05-11)
- PowerShell: 5.1 (Windows PowerShell) and 7.4 / 7.6 (pwsh)
- Last known-good version: 3.1.9
Workaround
Pin to < 3.2.0:
Install-Module ModuleBuilder -MaximumVersion 3.1.9 -Scope CurrentUser
Suggestion
Given #135 / #136 covered the same class of issue, a CI job that runs Import-Module on Windows PowerShell 5.1 (e.g. on windows-latest with shell: powershell) would catch this regression at PR time.
Summary
ModuleBuilder 3.2.0 (released 2026-05-11) introduces two regressions that block consumers that previously worked on v3.1.7 / v3.1.8:
ModuleBuilder.psm1uses PowerShell 7-only syntax.Build-Modulenow fails on PowerShell 7+ when the source manifest does not contain an uncommentedAliasesToExport— this used to be optional.Bug 1: Parse errors on Windows PowerShell 5.1
Import-Module ModuleBuilderfails before any user code runs:Root causes in the shipped
.psm1:? :(PowerShell 7+ only)|(PowerShell 7+ only)This is a regression of the same class as #135 / fixed in #136 — PS 5.1 parse errors caused by newer-syntax constructs in code paths that PS 5.1 has to parse at module-load time.
Bug 2:
AliasesToExportnow mandatory on PowerShell 7+Even where the module imports successfully (i.e. on PS 7),
Build-Modulenow rejects source manifests that haveAliasesToExportcommented out:The field was optional in v3.1.x. It is unclear from the changelog whether this is intentional (in which case it is a breaking change that should be documented and major-version-bumped) or an unintended side-effect.
Repro
Install-Module ModuleBuilder -RequiredVersion 3.2.0Import-Module ModuleBuilder→ parse error.# AliasesToExport = @()commented out:Build-Module→Get-Metadataerror.Environment
Workaround
Pin to
< 3.2.0:Suggestion
Given #135 / #136 covered the same class of issue, a CI job that runs
Import-Moduleon Windows PowerShell 5.1 (e.g. onwindows-latestwithshell: powershell) would catch this regression at PR time.