🪲 [Fix]: Install built modules into their real manifest version folder#19
Merged
Marius Storhaug (MariusStorhaug) merged 6 commits intoJul 8, 2026
Merged
Conversation
Install-PSModule copied the built module into a hard-coded 999.0.0 folder, so Import-Module failed once the manifest carried a real (non-placeholder) version. Read the manifest ModuleVersion and install into the matching version folder, falling back to 999.0.0 only when the manifest is unstamped.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 8, 2026 00:58
View session
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/Process-PSModule
that referenced
this pull request
Jul 8, 2026
…lpers to PR#19 branch Fix the hard-coded Import-Module -RequiredVersion 999.0.0 in the Pester Prescript to use the resolved module version. Temporarily pin Install-PSModuleHelpers to the fix/install-real-module-version branch (PSModule/Install-PSModuleHelpers#19) to validate end-to-end; will repin to the released tag before merge.
There was a problem hiding this comment.
Pull request overview
This PR updates Install-PSModule to install built PowerShell modules into a versioned folder matching the module manifest’s ModuleVersion, fixing import failures now that builds stamp the real version instead of the 999.0.0 placeholder.
Changes:
- Read
ModuleVersionfrom the module manifest and use it as the version folder name. - Fall back to
999.0.0only when the manifest version is missing/unstamped.
Comments suppressed due to low confidence (1)
src/Helpers/Helpers.psm1:329
Import-Module -Name $moduleNamecan import a different installed version if multiple versions of the module exist in$env:PSModulePath. Previously the hard-coded999.0.0made the installed copy win as the highest version; now that you install to the real version folder, it’s safer to import by the manifest path (or require the version) to ensure the freshly-copied module is the one that gets loaded.
Copy-Item -Path "$Path/*" -Destination $codePath -Recurse -Force
Write-Host '::group::Importing module'
Import-Module -Name $moduleName -Verbose
Write-Host '::endgroup::'
if ($PassThru) {
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 8, 2026 01:05
View session
…ifest path Addresses review feedback: build the install path with Join-Path (cross-platform separators) and import the just-installed module by its manifest path so it is not shadowed by another version already on PSModulePath.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 8, 2026 01:08
View session
Add -Force so the just-installed copy replaces any already-loaded version of the same module, guaranteeing the correct version is used by downstream tests.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 8, 2026 01:11
View session
Join-Path -AdditionalChildPath is PowerShell 6+ only; nested Join-Path calls keep the same behavior while remaining compatible with Windows PowerShell 5.1.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 8, 2026 01:13
View session
Parse ModuleVersion as [version] and fail fast on a malformed value so a crafted manifest cannot inject path separators/traversal into the install path. Empty/unstamped manifests still fall back to the 999.0.0 placeholder.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 8, 2026 01:17
View session
This was referenced Jul 8, 2026
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 8, 2026 10:10
View session
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/Test-PSModule
that referenced
this pull request
Jul 8, 2026
Built modules whose manifests carry a real, resolved version can now be tested by `Test-PSModule`. Previously the action installed the built module under the historical `999.0.0` placeholder folder, so module tests failed once the build flow started stamping manifests with the version that will actually be shipped. ## Fixed: Built modules with resolved versions can be tested `Test-PSModule` now installs and validates built module outputs whose manifest `ModuleVersion` has already been resolved to the real build version. The module is installed under a matching version folder before module tests run, so PowerShell accepts the manifest and Pester validates the artifact from the expected path. This is delivered by bumping the pinned `PSModule/Install-PSModuleHelpers` to `v1.0.8`, which installs built modules at their real version instead of the `999.0.0` placeholder. ## Technical Details - `action.yml`: `PSModule/Install-PSModuleHelpers` pin bumped `v1.0.7` -> `v1.0.8` (the release from [PSModule/Install-PSModuleHelpers#19](PSModule/Install-PSModuleHelpers#19)). - `src/tests/Module/PSModule/PSModule.Tests.ps1`: new test asserting the installed version folder matches the manifest `ModuleVersion`, guarding against a regression to the `999.0.0` behavior. - `tests/outputTestRepo/outputs/module/PSModuleTest/PSModuleTest.psd1`: fixture `ModuleVersion` updated `999.0.0` -> `3.0.11` to model the current build output. - The branch is merged up to date with `main`, which already carries the `actions/checkout` v7.0.0, `super-linter` v8.7.0, and `PSModule/Invoke-Pester` v4.2.6 pins, so this PR no longer changes those.
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/Document-PSModule
that referenced
this pull request
Jul 9, 2026
PR PSModule/Install-PSModuleHelpers#19 is merged and released as v1.0.8. Replace the TEMP branch pin with the released v1.0.8 commit SHA.
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/Document-PSModule
that referenced
this pull request
Jul 9, 2026
…PSModuleHelpers) (#52) ## What `Document-PSModule` installs the built module (via `Install-PSModule` from `Install-PSModuleHelpers`) before generating docs. That helper used to copy the module into a hard-coded `999.0.0` folder, which breaks now that [Process-PSModule#326](PSModule/Process-PSModule#326) stamps the real version at build time (folder no longer matches the manifest, so `Import-Module` fails and `Build-Docs` breaks). ## Change Bump the `Install-PSModuleHelpers` pin to the version that installs into a folder matching the manifest `ModuleVersion` ([PSModule/Install-PSModuleHelpers#19](PSModule/Install-PSModuleHelpers#19)). > **Pinned to the released tag:** [PSModule/Install-PSModuleHelpers#19](PSModule/Install-PSModuleHelpers#19) is merged and released, so this now pins [`v1.0.8`](https://github.com/PSModule/Install-PSModuleHelpers/releases/tag/v1.0.8). Part of the [Process-PSModule#326](PSModule/Process-PSModule#326) refactor.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Install-PSModulecopied the built module into a hard-coded.../<name>/999.0.0folder and thenImport-Moduled it. That only worked while the build pipeline stamped the999.0.0placeholder into every manifest. Now that Process-PSModule#326 resolves and stamps the real version at build time, the folder name (999.0.0) no longer matches the manifestModuleVersion, so PowerShell rejects the module ("does not have a valid module manifest file") andImport-Modulefails.Change
Read the manifest
ModuleVersionand install into the matching version folder. Fall back to999.0.0only when the manifest is unstamped (a build that opted out of version resolution), preserving the previous behaviour for that case.Import the freshly installed manifest path with
-Force -Globalso a preloaded placeholder version does not keep command resolution pinned to999.0.0.Validation
Added
tests/Install-PSModule.Tests.ps1and wired it intoAction-Test. The regression test covers real-version installation, absence of the999.0.0folder for stamped manifests, replacement of a preloaded999.0.0command, and rejection of malformedModuleVersionvalues.Local validation passed:
pwsh -NoProfile -File ./tests/Install-PSModule.Tests.ps1Invoke-ScriptAnalyzer -Path . -Recurse -Settings .github/linters/.powershell-psscriptanalyzer.psd1./src/main.ps1,Get-Module -Name Helpers -ListAvailable, then the regression scriptPart of the Process-PSModule#326 "test what you ship" refactor (test-harness version-awareness). Consumed by
Test-PSModule,Document-PSModule, and the Process-PSModuleTest-Modulejob.