fix: drop flaky profile-based compatibility analyzer rules

PSUseCompatibleCommands and PSUseCompatibleTypes intermittently threw a
NullReferenceException inside Invoke-ScriptAnalyzer on the macOS CI runner,
aborting the Analyze task (it passed on the first run, then failed on a
re-run with identical settings; ubuntu and windows passed both times). They
also produced false positives that required per-function suppressions
(Get-ChildItem -CodeSigningCert provider dynamic parameter; Invoke-Pester
-Configuration from the required Pester 5+).

Keep only PSUseCompatibleSyntax, which catches the actual regression class
(PowerShell 7+-only syntax such as the ternary operator), performs no
compatibility-profile deserialization, and is not subject to that NRE. The
two suppressions are removed as no longer needed. Core-only cmdlet/type
usage remains covered by the Windows PowerShell 5.1 import-smoke CI job.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: tablackburn

CHANGELOG.md

@@ -24,11 +24,12 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 
 - Cross-version compatibility guardrails so a PowerShell 7+-only construct cannot
   silently break the lowest supported engine again:
-  - The `PSUseCompatibleSyntax`, `PSUseCompatibleCommands`, and
-    `PSUseCompatibleTypes` rules are enabled in
+  - The `PSUseCompatibleSyntax` rule is enabled in
     `PowerShellBuild/ScriptAnalyzerSettings.psd1` (targeting Windows PowerShell 5.1
-    and PowerShell 7), and the `Analyze` build task now fails on any compatibility
-    violation.
+    and PowerShell 7), and the `Analyze` build task now fails on a compatibility
+    violation. It checks the target language version regardless of the engine it
+    runs under, so a ternary (or other PowerShell 7+-only syntax) is caught even
+    from `pwsh`.
   - A new `Import smoke (Windows PowerShell 5.1)` CI job parses and imports the
     module on the real lowest-supported engine.
 

PowerShellBuild/Public/Get-PSBuildCertificate.ps1

@@ -88,11 +88,6 @@ function Get-PSBuildCertificate {
         'CertificatePasswordEnvVar',
         Justification = 'This is not a password in plain text. It is the name of an environment variable that contains the password, which is a common pattern for CI/CD pipelines and secrets management.'
     )]
-    [Diagnostics.CodeAnalysis.SuppressMessageAttribute(
-        'PSUseCompatibleCommands',
-        '',
-        Justification = 'Get-ChildItem -CodeSigningCert is a dynamic parameter supplied by the Certificate (Cert:) provider, not a static parameter of Get-ChildItem, so the static command data used by PSUseCompatibleCommands cannot see it. It is available on both Windows PowerShell 5.1 and PowerShell 7+.'
-    )]
     param(
         [ValidateSet('Auto', 'Store', 'Thumbprint', 'EnvVar', 'PfxFile')]
         [string]$CertificateSource = 'Auto',

PowerShellBuild/Public/Test-PSBuildPester.ps1

@@ -36,11 +36,6 @@ function Test-PSBuildPester {
         Run Pester tests in ./tests and save results to ./out/testResults.xml
     #>
     [CmdletBinding()]
-    [Diagnostics.CodeAnalysis.SuppressMessageAttribute(
-        'PSUseCompatibleCommands',
-        '',
-        Justification = 'Invoke-Pester -Configuration is a Pester 5+ parameter. This module requires Pester >= 5.6.1 (see RequiredModules in the manifest) and imports Pester with -MinimumVersion 5.0.0 before use, so the parameter is always available at runtime. The bundled PSUseCompatibleCommands profiles captured an older Pester, producing a false positive on both Windows PowerShell 5.1 and PowerShell 7.'
-    )]
     param(
         [parameter(Mandatory)]
         [string]$Path,

PowerShellBuild/ScriptAnalyzerSettings.psd1

@@ -10,29 +10,22 @@
             Whitelist = @('task')
         }
 
-        # Cross-version compatibility guardrails. PowerShellBuild still supports
-        # Windows PowerShell 5.1 (Desktop) per the manifest, so these rules flag any
-        # syntax, command, or type that would not work on the lowest supported engine.
-        # PSUseCompatibleSyntax checks against the target language versions regardless
-        # of the engine the analyzer runs under, so a PowerShell 7+-only construct (for
-        # example the ternary operator) is caught even when the analyzer runs from pwsh.
+        # Cross-version compatibility guardrail. PowerShellBuild still supports Windows
+        # PowerShell 5.1 (Desktop) per the manifest, so this flags syntax that would not
+        # parse on the lowest supported engine. PSUseCompatibleSyntax checks against the
+        # target language versions regardless of the engine the analyzer runs under, so a
+        # PowerShell 7+-only construct (for example the ternary operator) is caught even
+        # when the analyzer runs from pwsh.
+        #
+        # The profile-based PSUseCompatibleCommands / PSUseCompatibleTypes rules are
+        # intentionally NOT enabled here: they produced false positives on this codebase
+        # (provider dynamic parameters and required-module commands) and intermittently
+        # threw a NullReferenceException inside Invoke-ScriptAnalyzer on some platforms,
+        # which aborts the whole analysis. Core-only cmdlet/type usage is instead covered
+        # by the Windows PowerShell 5.1 import-smoke CI job.
         PSUseCompatibleSyntax = @{
             Enable         = $true
             TargetVersions = @('5.1', '7.0')
         }
-        PSUseCompatibleCommands = @{
-            Enable         = $true
-            TargetProfiles = @(
-                'win-8_x64_10.0.17763.0_5.1.17763.316_x64_4.0.30319.42000_framework'
-                'win-8_x64_10.0.17763.0_7.0.0_x64_3.1.2_core'
-            )
-        }
-        PSUseCompatibleTypes = @{
-            Enable         = $true
-            TargetProfiles = @(
-                'win-8_x64_10.0.17763.0_5.1.17763.316_x64_4.0.30319.42000_framework'
-                'win-8_x64_10.0.17763.0_7.0.0_x64_3.1.2_core'
-            )
-        }
     }
 }

psakeFile.ps1

@@ -20,12 +20,12 @@ task Analyze -depends Build {
     $analysis = Invoke-ScriptAnalyzer -Path $settings.ModuleOutDir -Recurse -Verbose:$false -Settings $analyzerSettings
     $errors   = $analysis | Where-Object { $_.Severity -eq 'Error' }
 
-    # Cross-version compatibility violations (PSUseCompatibleSyntax/Commands/Types) are reported at
-    # Warning severity, but must always fail the build. A PowerShell 7+-only construct such as the
-    # ternary operator parses fine under pwsh yet breaks module import on Windows PowerShell 5.1,
-    # which the manifest still supports. PSUseCompatibleSyntax checks the target language versions
-    # regardless of the engine the analyzer runs under, so this gate catches such a regression even
-    # though CI runs the analysis from pwsh.
+    # Cross-version compatibility violations (PSUseCompatibleSyntax) are reported at Warning
+    # severity, but must always fail the build. A PowerShell 7+-only construct such as the ternary
+    # operator parses fine under pwsh yet breaks module import on Windows PowerShell 5.1, which the
+    # manifest still supports. PSUseCompatibleSyntax checks the target language versions regardless
+    # of the engine the analyzer runs under, so this gate catches such a regression even though CI
+    # runs the analysis from pwsh.
     $compatibilityIssues = $analysis | Where-Object { $_.RuleName -like 'PSUseCompatible*' }
 
     # Remaining warnings are reported but, per project policy, do not fail the build.