🩹 [Patch]: IsWindows PS 5.1 compatibility shim removed#132
Merged
Marius Storhaug (MariusStorhaug) merged 1 commit intomainfrom Apr 5, 2026
Merged
🩹 [Patch]: IsWindows PS 5.1 compatibility shim removed#132Marius Storhaug (MariusStorhaug) merged 1 commit intomainfrom
Marius Storhaug (MariusStorhaug) merged 1 commit intomainfrom
Conversation
PSModule targets PowerShell LTS (7.6+) where $IsWindows is a built-in automatic variable. The Desktop edition shim and its PSScriptAnalyzer suppressions are no longer needed.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
April 5, 2026 16:00
View session
Contributor
There was a problem hiding this comment.
Pull request overview
Removes the legacy PowerShell 5.1 $IsWindows compatibility shim and its PSScriptAnalyzer suppression attributes from generated root module (.psm1) output, aligning built modules with the PowerShell 7+ environment where $IsWindows is an automatic variable.
Changes:
- Removed injection of
SuppressMessageAttributeentries related to$IsWindowsfrom the generated module header. - Removed the
if ($PSEdition -eq 'Desktop') { $IsWindows = $true }block from the generated module post-header template.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/Test-PSModule
that referenced
this pull request
Apr 5, 2026
#113) Module tests now validate framework-injected boilerplate — type accelerator registration and OnRemove cleanup — so code coverage reflects actual test gaps instead of penalizing module authors for untested framework code. ## New: Type accelerator registration tests When `Build-PSModule` injects a class exporter region, the module tests now verify that every public class and enum listed in `$ExportableClasses` / `$ExportableEnums` is registered as a type accelerator after import. ``` Context Framework - Type accelerator registration [+] Should register public class [Book] as a type accelerator [+] Should register public class [BookList] as a type accelerator ``` Modules without a class exporter region skip these tests automatically. ## New: OnRemove cleanup tests A new test verifies that when the module is removed, its type accelerators are cleaned up via the `OnRemove` hook — preventing type collisions when re-importing or importing a different version. ``` Context Framework - Module OnRemove cleanup [+] Should clean up type accelerators when the module is removed ``` ## Changed: IsWindows compatibility shim removed The `$IsWindows = $true` PS 5.1 Desktop edition shim has been removed from `Build-PSModule` (see [PSModule/Build-PSModule#132](PSModule/Build-PSModule#132)). The corresponding test context and test fixture output have been removed here as well. PSModule targets PowerShell LTS (7.6+) where `$IsWindows` is a built-in automatic variable. ## Technical Details - `PSModule.Tests.ps1`: Discovery-phase variables (`$hasClassExporter`, `$expectedClassNames`, `$expectedEnumNames`) are computed at script scope for Pester's `-Skip`/`-ForEach` evaluation, then recomputed in a top-level `BeforeAll` for the Run phase. This dual-computation pattern is required because Pester v5 Discovery and Run are separate executions that don't share script-scope state. - `PSModuleTest.psm1` (test fixture): Updated to remove the `$IsWindows` shim and its suppression attributes, matching the new Build-PSModule output format. - PSScriptAnalyzer `PSUseDeclaredVarsMoreThanAssignments` suppressed at file level because the analyzer cannot trace variable flow across Pester's `BeforeAll` → `It` block boundaries.
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/Process-PSModule
that referenced
this pull request
Apr 5, 2026
…le authors (#310) Framework-generated boilerplate — type accelerator registration and `OnRemove` cleanup — is now tested and covered by updated action versions referenced in this workflow. The obsolete `$IsWindows` PS 5.1 shim is no longer injected into built modules. Coverage from the framework test step and the module test step is already aggregated by Get-CodeCoverage, so module authors' coverage percentages now reflect only the code they wrote. - Fixes #309 ## Changed: Build-PSModule updated to v4.0.14 Built modules no longer include the `$IsWindows = $true` Desktop edition shim or its PSScriptAnalyzer suppression attributes. PSModule targets PowerShell LTS (7.6+), where `$IsWindows` is a built-in automatic variable. See [PSModule/Build-PSModule#132](PSModule/Build-PSModule#132) for details. ## Changed: Test-PSModule updated to v3.0.10 The framework module tests now validate that every public class and enum is registered as a type accelerator after import, and that the `OnRemove` hook cleans them up when the module is removed. These tests produce coverage artifacts that are aggregated with module author test coverage, so framework-generated boilerplate no longer counts against the module author's coverage target. See [PSModule/Test-PSModule#113](PSModule/Test-PSModule#113) for details. ## Changed: README documents the framework testing design The README now explains: - Why framework-generated code is tested by the framework itself - How coverage from both the framework test step and the module test step is aggregated - That module authors do not need to test framework-generated code themselves ## Technical Details - `.github/workflows/Build-Module.yml`: Updated Build-PSModule from v4.0.13 to v4.0.14 (`345728124d201f371a8b0f1aacb98f89000a06dc`) - `.github/workflows/Test-Module.yml`: Updated Test-PSModule from v3.0.8 to v3.0.10 (`8c3337136dc7cf320da39eeb50e776d04bc9ac73`) - `.github/workflows/Test-SourceCode.yml`: Updated Test-PSModule from v3.0.8 to v3.0.10 - `README.md`: Added "Code coverage for framework-generated code" paragraph under the Framework test section; added coverage aggregation details under the Get code coverage section; removed reference to the `$IsWindows` shim - No workflow structure changes — code coverage was already enabled in Test-Module.yml and Get-PesterCodeCoverage already aggregates all `*-CodeCoverage` artifacts
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.
Built modules no longer include the
$IsWindows = $trueshim or its PSScriptAnalyzer suppression attributes. PSModule targets PowerShell LTS (7.6+), where$IsWindowsis a built-in automatic variable — the Desktop edition fallback is unnecessary.Changed: Built module root files are smaller and cleaner
The generated
.psm1files no longer contain the following block:And the module post-header no longer includes:
Modules built with this version require PowerShell 7.x+ (LTS). If you need PS 5.1 support, pin Build-PSModule to v4.
Technical Details
Build-PSModuleRootModule.ps1: Removed theAdd-Contentcall that injected the twoSuppressMessageAttributeentries and the empty here-string left after their removal. Removed theif ($PSEdition -eq 'Desktop')block from the module post-header template.