fix: quiet module load log (Verbose instead of Information)#470
Merged
Conversation
Test Results 4 files 288 suites 1m 17s ⏱️ Results for commit 6bb5dd9. ♻️ This comment has been updated with latest results. |
HeyItsGilbert
added a commit
that referenced
this pull request
Jun 19, 2026
## Summary The `Run Tests (PowerShell 5.1)` CI job has been failing on every PR (e.g. #468, #469, #470) during `build.ps1 -Bootstrap` with: ``` PSDepend\0.3.8\Private\SemanticVersion.ps1: Cannot add type. The type name 'System.Management.Automation.SemanticVersion' already exists. ``` ### Root cause PSDepend `0.3.8` ships an **unguarded** `Add-Type` for its Windows PowerShell 5.1 `SemanticVersion` polyfill: ```powershell if ($PSVersionTable.PSVersion.Major -lt 6) { Add-Type -TypeDefinition $code } ``` On PS 5.1, `System.Management.Automation.SemanticVersion` is not a built-in type, so this runs. When PSDepend is imported a **second time** in the same session — which the bootstrap triggers because PSDepend is pinned as a dependency of itself in `requirements.psd1` — the `Add-Type` throws, since the type already exists in the AppDomain. PowerShell 6+ is unaffected: the type is built in, so the guard short-circuits. PSDepend `0.4.1` (newly released) adds the missing existence guard, making the polyfill idempotent: ```powershell if ($PSVersionTable.PSVersion.Major -lt 6 -and -not ('System.Management.Automation.SemanticVersion' -as [type])) { Add-Type -TypeDefinition $code } ``` ### Fix Bump the PSDepend pin in `requirements.psd1` from `0.3.8` → `0.4.1`. ## Reproduction / verification Reproduced on local Windows PowerShell 5.1 (`5.1.26100`) by pre-defining the type then dot-sourcing each version's `SemanticVersion.ps1`: | PSDepend | Result | | --- | --- | | `0.3.8` | ❌ `Cannot add type. The type name 'System.Management.Automation.SemanticVersion' already exists.` | | `0.4.1` | ✅ no-op (guard skips `Add-Type`) | CI will confirm the PS 5.1 job goes green on this PR. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The "Plaster vX.Y.Z module loaded successfully" message was logged at Information level with -InformationAction Continue, so it printed on every import regardless of $env:PLASTER_LOG_LEVEL. Demote it (and the symmetric "module is being removed" message) to Verbose so they are silent by default and only surface when the user opts in via PLASTER_LOG_LEVEL=Verbose. The version already comes from the .psd1 ModuleVersion, so the message prints the correct installed version. Fixes #458 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The CI changelog linter (mindsers/changelog-reader-action, error level) validates the latest non-Unreleased entry. With the manifest fix as the only change, the latest entry was the released 2.1.2, which carries a "Changed" section illegal for a patch bump (2.1.1 -> 2.1.2), failing the check on every PR. Add a 2.1.3 entry containing only Fixed for this change and bump the manifest to match. The latest entry now validates as a clean patch and 2.1.2's released history is left untouched. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The CI changelog linter runs with validation_depth: 10, so it validates the ten newest released entries — not just the latest. 2.1.2 is a patch (2.1.1 -> 2.1.2) yet carried a "Changed" entry for the CI workflow migration (#457), which Keep a Changelog disallows for a patch bump. That CI migration is internal build infrastructure with no user-facing behavior change, so remove it from the changelog. 2.1.2 now validates as a clean patch (its genuine Fixed entries are unchanged), unblocking the linter for this and future PRs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2c80247 to
6bb5dd9
Compare
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.
Summary
Closes #458.
The
Plaster vX.Y.Z module loaded successfully (...)line printed on every import because it was logged atInformationlevel viaWrite-Information -InformationAction Continue, which forces display regardless of$env:PLASTER_LOG_LEVEL.This demotes that message — and the symmetric
Plaster module is being removedmessage — toVerbose. They are now silent by default and only surface when a user opts in withPLASTER_LOG_LEVEL=Verbose(and a visible verbose stream).The version is already read dynamically from the manifest (
Import-PowerShellDataFile … .ModuleVersion), so the message prints the correct installed version (e.g.v2.1.2). The reporter sawv2.0.0only because that was their installed build.Changes
Plaster/Plaster.psm1:Write-PlasterLog -Level Information→-Level Verbosefor both the load and removal messages.Testing
Import-Module Plaster— no output (silent). ✅$env:PLASTER_LOG_LEVEL='Verbose'; $VerbosePreference='Continue'; Import-Module Plaster -Force— emits[Verbose] [Plaster] Plaster v2.1.2 module loaded successfully (PowerShell 7.6.2). ✅🤖 Generated with Claude Code