{"id":18370,"date":"2020-05-04T14:17:17","date_gmt":"2020-05-04T22:17:17","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/powershell\/?p=18370"},"modified":"2022-05-23T09:41:53","modified_gmt":"2022-05-23T17:41:53","slug":"psscriptanalyzer-pssa-1-19-0-has-been-released","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/psscriptanalyzer-pssa-1-19-0-has-been-released\/","title":{"rendered":"PSScriptAnalyzer (PSSA) 1.19.0 has been released"},"content":{"rendered":"<h2><a id=\"user-content-tldr-too-long-didnt-read\" class=\"anchor\" href=\"#tldr-too-long-didnt-read\" aria-hidden=\"true\"><\/a>TL;DR; (Too Long; Didn&#8217;t Read)<\/h2>\n<p>This new minor version brings 5 new rules, the formatter is much faster and other enhancements and fixes. You can get it from the PSGallery\u00a0<a href=\"https:\/\/www.powershellgallery.com\/packages\/PSScriptAnalyzer\/1.19.0\" rel=\"nofollow\">here<\/a>. At the same time the PowerShell extension for VS Code has released a new preview version. This ships with this new version of PSSA so that you can also take advantage of all the new configuration options. Therefore, whenever we reference the next version of the extension below, we mean the recently updated preview version or the next, upcoming release of the GA version. You can still take advantage of the new PSSA release in the GA version of the extension as well now by installing the module locally via\u00a0<code>Install-Module -Name PSScriptAnalyzer -Scope CurrentUser -Force<\/code>, but you won&#8217;t have access to the configuration settings of some of the new features. The full changelog is\u00a0<a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/CHANGELOG.MD\">here<\/a>.<\/p>\n<h2><a id=\"user-content-new-script-analysis-rules\" class=\"anchor\" href=\"#new-script-analysis-rules\" aria-hidden=\"true\"><\/a>New Script Analysis Rules<\/h2>\n<p>There are a total of five new analyzer rules and they were all added by the community!<\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/AvoidLongLines.md\">AvoidLongLines<\/a>\u00a0(thanks\u00a0<a href=\"https:\/\/twitter.com\/MrThomasRayner\" rel=\"nofollow\">Thomas Rayner<\/a>!): Warns when a line is too long (default is 120 characters) but is not enabled by default.<\/li>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/AvoidOverwritingBuiltInCmdlets.md\">AvoidOverwritingBuiltInCmdlets<\/a>\u00a0(thanks\u00a0<a href=\"https:\/\/twitter.com\/MrThomasRayner\" rel=\"nofollow\">Thomas Rayner<\/a>!): Warns you if you accidentally try to re-define a built-in cmdlet such as e.g.\u00a0<code>Get-Item<\/code>\u00a0by writing code like e.g.\u00a0<code>function Get-Item { }<\/code>.<\/li>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/UseUsingScopeModifierInNewRunspaces.md\">UseUsingScopeModifierInNewRunspaces<\/a>\u00a0(thanks\u00a0<a href=\"https:\/\/twitter.com\/Jawz_84\" rel=\"nofollow\">Jos Koelewijn<\/a>!): Warns you when trying to incorrectly reference a variable that is not defined directly in the scope of the current scriptblock. This applies e.g. to the\u00a0<code>-Command<\/code>\u00a0parameter of\u00a0<code>Invoke-Command<\/code>\u00a0or\u00a0<code>-Parallel<\/code>\u00a0of\u00a0<code>ForEach-Object<\/code>\u00a0(added in PowerShell 7, see blog\u00a0<a href=\"https:\/\/devblogs.microsoft.com\/powershell\/powershell-foreach-object-parallel-feature\/\" rel=\"nofollow\">here<\/a>). It recommends to use the\u00a0<code>$using<\/code>\u00a0scope modifier to reference the variable correctly.<\/li>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/UseProcessBlockForPipelineCommand.md\">UseProcessBlockForPipelineCommand<\/a>\u00a0(thanks\u00a0<a href=\"https:\/\/twitter.com\/mcnabbmh\" rel=\"nofollow\">Matt McNabb<\/a>!): Warns when a function declares support for pipeline input (via the\u00a0<code>[Parameter(ValueFromPipeline)]<\/code>\u00a0attribute) that the function needs to declare a\u00a0<code>process { }<\/code>\u00a0block.<\/li>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/ReviewUnusedParameter.md\">ReviewUnusedParameter<\/a>\u00a0(thanks\u00a0<a href=\"https:\/\/twitter.com\/mcnabbmh\" rel=\"nofollow\">Matt McNabb<\/a>!): Warns on parameters declared in a script, scriptblock, or function scope that have not been used in that scope. You can think of it as the equivalent of the\u00a0<code>UseDeclaredVarsMoreThanAssignments<\/code>\u00a0rule but for parameters instead of variables.<\/li>\n<\/ul>\n<p>The added computational work for those rules are being compensated for by a performance improvement in the\u00a0<code>AvoidTrailingWhitespace<\/code>\u00a0rule, therefore the speed of running\u00a0<code>Invoke-ScriptAnalyzer<\/code>\u00a0for all rules is roughly the same compared to the previous version of PSScriptAnalyzer.<\/p>\n<h2><a id=\"user-content-formatter\" class=\"anchor\" href=\"#formatter\" aria-hidden=\"true\"><\/a>Formatter<\/h2>\n<h3><a id=\"user-content-performance\" class=\"anchor\" href=\"#performance\" aria-hidden=\"true\"><\/a>Performance<\/h3>\n<p>Several improvements have been made to the formatting rules and the engine that should result in the formatter being multiple times faster, especially for large scripts. The improvements were:<\/p>\n<ul>\n<li>Reduced initialisation overhead.<\/li>\n<li>Improved efficiency of formatting rules, which addresses the scaling problems that were seen for large scripts.<\/li>\n<li>Reduced number of times the script text has to be re-parsed. In its current architecture, the formatter has to re-parse the script after every rule run and every applied correction. When a rule has no violations then the parsed AST and tokens are being recycled. This leads to faster formatting when no or only some correction have to be made.<\/li>\n<\/ul>\n<p>To give a specific example, running the formatter on\u00a0<a href=\"https:\/\/github.com\/PowerShell\/PowerShell\">PowerShell<\/a>&#8216;s\u00a0<a href=\"https:\/\/github.com\/PowerShell\/PowerShell\/blob\/master\/build.psm1\">build.psm1<\/a>\u00a0module, which has over 3000 lines, we&#8217;ve measure the following times for a &#8216;warm&#8217; run:<\/p>\n<ul>\n<li>Version 1.18.3 takes around 1,250 ms.<\/li>\n<li>Version 1.19.0 takes around 550 ms.<\/li>\n<li>Version 1.19.0 takes around 170 ms on the pre-formatted file.<\/li>\n<\/ul>\n<p>The reason why we measure a &#8216;warm&#8217; run is because in the editor scenario, the PowerShell extension will have likely already finished a run\u00a0<code>Invoke-ScriptAnalyzer<\/code>\u00a0in the background on the script, which means the\u00a0<a href=\"https:\/\/docs.microsoft.com\/dotnet\/api\/system.management.automation.commandinfo\" rel=\"nofollow\">CommandInfo<\/a>\u00a0cache has already been populated. Although the default set of formatting rules in the PowerShell extension for VS Code doesn&#8217;t need the CommandInfo cache so there isn&#8217;t much of a difference between cold and warm for most users, the following 2 optional rules do use the CommandInfo:<\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/UseCorrectCasing.md\">UseCorrectCasing<\/a>: Controlled via the\u00a0<code>powershell.codeFormatting.useCorrectCasing<\/code>\u00a0setting of the PowerShell extension for VS Code.<\/li>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/AvoidUsingCmdletAliases.md\">AvoidUsingCmdletAliases<\/a>: Controlled via the\u00a0<code>powershell.codeFormatting.autoCorrectAliases<\/code>\u00a0setting of the PowerShell extension for VS Code.<\/li>\n<\/ul>\n<h3><a id=\"user-content-new-formatter-features\" class=\"anchor\" href=\"#new-formatter-features\" aria-hidden=\"true\"><\/a>New Formatter features<\/h3>\n<ul>\n<li>Parameter Casing: The\u00a0<a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/UseCorrectCasing.md\">UseCorrectCasing<\/a>\u00a0rule now correct also the casing of parameters and not just the cmdlet names.<\/li>\n<li>The\u00a0<code>PipelineIndentationStyle<\/code>\u00a0setting of\u00a0<code>UseConsistentIndentation<\/code>\u00a0has a new option now and will also become the default setting in the next version of the PowerShell extension for VS Code. The new value is named\u00a0<code>None<\/code>\u00a0and will not change the user&#8217;s pipeline indentation at all which makes this feature an opt-in scenario. For the previous non-default settings\u00a0<code>IncreaseIndentationForFirstPipeline<\/code>\u00a0and\u00a0<code>IncreaseIndentationAfterEveryPipeline<\/code>\u00a0all new user reported bugs are fixed now and therefore we encourage you to please try it out again.<\/li>\n<li>The\u00a0<a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/UseConsistentWhitespace.md\">UseConsistentWhitespace<\/a>\u00a0option\u00a0<code>CheckPipe<\/code>\u00a0has not been changed to only ADD whitespace around the pipe if it is missing but does not remove extraneous whitespace. This is because some people prefer to line up their pipelines in Pester tests. For anyone who still wants to trim redundant whitespace around pipes, the new\u00a0<code>CheckPipeForRedundantWhitespace<\/code>\u00a0option has been provided. For users of the PowerShell extension for VS Code this means that in the next version of the PowerShell extension for VS Code we plan to split the existing\u00a0<code>powershell.codeFormatting.whitespaceAroundPipe<\/code>\u00a0(enabled by default) setting into 2 new ones:\u00a0<code>powershell.codeFormatting.addWhitespaceAroundPipe<\/code>\u00a0(enabled by default) and\u00a0<code>powershell.codeFormatting.trimWhitespaceAroundPipe<\/code> (disabled by default). The preview extension will automatically create the <code>addWhitespaceAroundPipe<\/code> setting for you with the value of <code>whitespaceAroundPipe<\/code> if you are using this setting.\u00a0In the next stable extension, the left-over <code>whitespaceAroundPipe<\/code> setting will be removed completely.<\/li>\n<li>The\u00a0<a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/UseConsistentWhitespace.md\">UseConsistentWhitespace<\/a>\u00a0option\u00a0<code>CheckParameter<\/code>\u00a0has been added and you will be able to control it via this setting of the PowerShell extension for VS Code in its next update:\u00a0<code>powershell.codeFormatting.whitespaceBetweenParameters<\/code>.<\/li>\n<\/ul>\n<h2><a id=\"user-content-other-improvements\" class=\"anchor\" href=\"#other-improvements\" aria-hidden=\"true\"><\/a>Other improvements<\/h2>\n<ul>\n<li>The compatibility rules were updated to includes profiles for PowerShell 7; support single number version strings; and analysis for PowerShell 7 syntax (null-conditional method invocation, null-coalescing operator, ternary expression and pipeline chain operator).<\/li>\n<li><a href=\"https:\/\/github.com\/PowerShell\/PSScriptAnalyzer\/blob\/master\/RuleDocumentation\/AvoidAssignmentToAutomaticVariable.md\">AvoidAssignmentToAutomaticVariable<\/a>\u00a0rule was enhanced to include not only warn on read-only\u00a0<a href=\"https:\/\/docs.microsoft.com\/powershell\/module\/microsoft.powershell.core\/about\/about_automatic_variables\" rel=\"nofollow\">automatic variables<\/a>, but also other automatic variables that can but should not be assigned to, which also includes the commonly misused\u00a0<code>$input<\/code>\u00a0variable.<\/li>\n<li>The minimum supported version of PowerShell Core is\u00a0<code>6.2.4<\/code>\u00a0now but please bear in mind that support for PowerShell\u00a0<code>6.2<\/code>\u00a0itself ends on September 04 2020, see support policy\u00a0<a href=\"https:\/\/docs.microsoft.com\/en-us\/powershell\/scripting\/powershell-support-lifecycle?view=powershell-7#powershell-releases-end-of-life\" rel=\"nofollow\">here<\/a>.<\/li>\n<li>Our CI system has been migrated to use multi-stage Azure Pipelines, meaning that every commit gets tested against\u00a0<code>Windows<\/code>\u00a0(Server 2016 and 2019),\u00a0<code>Ubuntu<\/code>\u00a0(<code>16.04<\/code>\u00a0and\u00a0<code>18.04<\/code>) and\u00a0<code>macOS<\/code>\u00a0(<code>10.14<\/code>\u00a0and\u00a0<code>10.15<\/code>) for PowerShell 7 and also Windows PowerShell 5.1. The previous AppVeyor build still provides coverage for PowerShell 4 and before the release a manual test was executed to guarantee functionality for PowerShell 3.<\/li>\n<\/ul>\n<h2><a id=\"user-content-whats-next\" class=\"anchor\" href=\"#whats-next\" aria-hidden=\"true\"><\/a>What&#8217;s next?<\/h2>\n<p>As mentioned in multiple, previous posts\u00a0<a href=\"https:\/\/devblogs.microsoft.com\/powershell\/release-of-powershell-script-analyzer-psscriptanalyzer-1-18-2\/\" rel=\"nofollow\">here<\/a>\u00a0and\u00a0<a href=\"https:\/\/devblogs.microsoft.com\/powershell\/powershell-7-1-team-investments-and-preview-1-release\/\" rel=\"nofollow\">here<\/a>, the PowerShell team is looking at a partial re-write of PSScriptAnalyzer, which will require a bump of the major version. Version\u00a0<code>1.x<\/code>\u00a0continues to be supported for PowerShell 3 and 4, but will not receive new features and only critical security fixes. In version\u00a0<code>2.x<\/code>, support for PowerShell version 3 and 4 are expected to be dropped.<\/p>\n<p>On behalf of the Script Analyzer team,<\/p>\n<p><a href=\"https:\/\/twitter.com\/CBergmeister\" rel=\"nofollow\">Christoph Bergmeister<\/a>, Project Maintainer from the community,\u00a0<a href=\"https:\/\/www.bjss.com\/\" rel=\"nofollow\">BJSS<\/a><\/p>\n<p><a href=\"https:\/\/twitter.com\/jwtruher\" rel=\"nofollow\">Jim Truher<\/a>, Senior Software Engineer, PowerShell Team, Microsoft<\/p>\n<p><a href=\"https:\/\/twitter.com\/rjmholt\" rel=\"nofollow\">Rob Holt<\/a>, Software Engineer, PowerShell team, Microsoft<\/p>\n","protected":false},"excerpt":{"rendered":"<p>TL;DR; (Too Long; Didn&#8217;t Read) This new minor version brings 5 new rules, the formatter is much faster and other enhancements and fixes. You can get it from the PSGallery\u00a0here. At the same time the PowerShell extension for VS Code has released a new preview version. This ships with this new version of PSSA so [&hellip;]<\/p>\n","protected":false},"author":2413,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[3182],"class_list":["post-18370","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell","tag-psscriptanalyzer"],"acf":[],"blog_post_summary":"<p>TL;DR; (Too Long; Didn&#8217;t Read) This new minor version brings 5 new rules, the formatter is much faster and other enhancements and fixes. You can get it from the PSGallery\u00a0here. At the same time the PowerShell extension for VS Code has released a new preview version. This ships with this new version of PSSA so [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/18370","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/2413"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=18370"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/18370\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=18370"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=18370"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=18370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}