Severity: Info
File: src/Servy.CLI/Servy.psm1 line 1
Description:
The module header comment documents Requires : PowerShell 2.0 or later (line 12) and the codebase enforces 2.0 compatibility in review (no [PSCustomObject]@{}, [ordered], Invoke-RestMethod, etc.). There is no #Requires -Version 2.0 directive at the top of the file, so the host has no programmatic way to refuse loading on an older shell and, more importantly, there is no early-fail signal when a future edit accidentally introduces a 3.0-only construct.
<#
.SYNOPSIS
Servy PowerShell module ...
.NOTES
Requires : PowerShell 2.0 or later # documentation only
#>
# no #Requires directive
Suggested fix:
Add #Requires -Version 2.0 as the first line of the file (before the comment block). A complementary CI lint step that loads the module on a PowerShell 2.0 host (Windows Server 2012 R2 runner, or a PS 5+ host with -Version 2 compatibility mode) would make the constraint self-enforcing rather than policed by review.
Severity: Info
File:
src/Servy.CLI/Servy.psm1line 1Description:
The module header comment documents
Requires : PowerShell 2.0 or later(line 12) and the codebase enforces 2.0 compatibility in review (no[PSCustomObject]@{},[ordered],Invoke-RestMethod, etc.). There is no#Requires -Version 2.0directive at the top of the file, so the host has no programmatic way to refuse loading on an older shell and, more importantly, there is no early-fail signal when a future edit accidentally introduces a 3.0-only construct.Suggested fix:
Add
#Requires -Version 2.0as the first line of the file (before the comment block). A complementary CI lint step that loads the module on a PowerShell 2.0 host (Windows Server 2012 R2 runner, or a PS 5+ host with-Version 2compatibility mode) would make the constraint self-enforcing rather than policed by review.