Summary of the new feature
There is currently one PSScriptAnalyzerSettings.psd1 file shipped with the PSScriptAnalyzer but there are (at least) two type phases that require a different use cases:
-
Development
During this phase (often done is VSCode or Visual Studio), any cutting-edge alert for a potential PowerShell pitfall is welcomed.
-
Building
During this phase (e.g. a CI/CD street), any change is supposed to passed the given tests.
Apparently, there is a (undocumented?) convention that our convention is to ship it opt-in via ConfigurableRule with Enable = false but that convention only satisfies the builder phase.
Proposed technical implementation details (optional)
Ship the PSScriptAnalyzer with an additional settings file that is focused on the development phase.
The "development" settings file might than be used as a default by e.g. VSCode (powershell.scriptAnalysis.settingsPath).
Caveats
What is the latest version of PSScriptAnalyzer at the point of writing
1.25.0
Summary of the new feature
There is currently one
PSScriptAnalyzerSettings.psd1file shipped with the PSScriptAnalyzer but there are (at least) two type phases that require a different use cases:Development
During this phase (often done is VSCode or Visual Studio), any cutting-edge alert for a potential PowerShell pitfall is welcomed.
Building
During this phase (e.g. a CI/CD street), any change is supposed to passed the given tests.
Apparently, there is a (undocumented?) convention that our convention is to ship it opt-in via
ConfigurableRulewithEnable = falsebut that convention only satisfies the builder phase.Proposed technical implementation details (optional)
Ship the PSScriptAnalyzer with an additional settings file that is focused on the development phase.
The "development" settings file might than be used as a default by e.g. VSCode (
powershell.scriptAnalysis.settingsPath).Caveats
What is the latest version of PSScriptAnalyzer at the point of writing
1.25.0