This applies especially to its usage within the VS Code PowerShell extension:<\/p>\n Please try out this new patch, if you install it using\u00a0PSScriptAnalyzer<\/code>\u00a0(PSSA<\/code>)\u00a01.18.1<\/code>\u00a0is now available on the\u00a0PSGallery<\/a>\u00a0and fixes not only a lot of the issues reported for\u00a01.18.0<\/code>\u00a0but has also been made twice as faster compared to\u00a01.18.0<\/code>. Additionally, the\u00a0-SaveDscDependency<\/code>\u00a0switch on\u00a0Invoke-ScriptAnalyzer<\/code>has been improved to be platform agnostic and should now also work on Linux systems if DSC has been set up. A long standing concurrency bug related to analysing module manifest has also been\u00a0fixed<\/a>. Analysis showed that\u00a0Test-ModuleManifest<\/code>\u00a0is not thread-safe due to a bug either in the cmdlet or in the PowerShell engine itself, we resolved it by having a lock around calls to this cmdlet.<\/p>\nFormatter Fixes<\/h3>\n
\n
PSUseCorrectCasing<\/code>\u00a0formatting rule had to be adjusted to not expand\/change paths and to treat wildcard characters correctly. Under the hood the rule calls\u00a0Get-Command<\/code>\u00a0and because\u00a0Get-Command ?<\/code>\u00a0returns all commands that have a name of length 1, it returned\u00a0ForEach-Object<\/code>\u00a0first, which made PSSA incorrectly change the\u00a0?<\/code>\u00a0alias for\u00a0Where-Object<\/code>\u00a0to\u00a0ForEach-Object<\/code>. The PowerShell VS Code extension has the\u00a0powershell.codeFormatting.useCorrectCasing<\/code>\u00a0setting that wraps around this configuration and the setting is currently defaulting to\u00a0false<\/code>\u00a0due to those issues that were found. With PSSA\u00a01.18.1<\/code>, we’d encourage you to enable the setting again as we think that we have fixed all issues and pending feedback we plan to enable the setting by default. Although the VS Code extension ships a backup version of PSSA (currently\u00a01.18.0<\/code>), one can always install PSScriptAnalyzer locally and the extension will pick it up. You can install the newer PSScriptAnalyzer version and start using it without having to wait for the extension to release an update.<\/li>\nPipelineIndentation<\/code>\u00a0configuration setting of the\u00a0PSUseConsistentIndentation<\/code>\u00a0formatting rule had a bug when it was set to\u00a0IncreaseIndentationForFirstPipeline<\/code>\u00a0or\u00a0IncreaseIndentationAfterEveryPipeline<\/code>\u00a0and in certain cases, indentation of code following the pipeline could be incorrectly indented. Currently the VS Code setting\u00a0powershell.codeFormatting.pipelineIndentationStyle<\/code>\u00a0for it is set to\u00a0NoIndentation<\/code>\u00a0to avoid this bug. We encourage you here as well to try out the options again so that we can get feedback before we set the default of the VS Code setting to\u00a0IncreaseIndentationForFirstPipeline<\/code>\u00a0(which is the default when calling\u00a0Invoke-Formatter<\/code>\u00a0without parameters). This desired default was voted for by the community\u00a0here<\/a>.<\/li>\n<\/ul>\nConclusion and Future Outlook<\/h3>\n
Install-Module<\/code>\u00a0then the VS Code extension will automatically use it after a restart of the integrated terminal session or just by re-opening VS Code. Getting feedback in this period is very important so that the PowerShell team can make a decision on when to include\u00a01.18.1<\/code>\u00a0by default in one of the next updates of the PowerShell extension. After feedback of this phased rollout, we will consider changing the default settings in the extension as mentioned above. It is hard to anticipate all the use cases, so we chose to make features configurable behind new flags and rollout the changes to a smaller user group first.<\/p>\n