Inaccurate PSScriptAnalyzer "Line has trailing whitespace" errors since 1.8.0

[stukey]

Since the update to the PowerShell Extension 1.8.0 (and 1.8.1) I am seeing 100s of alerts about my scripts in the 'Problems' section of VSCode indicating "[PSScriptAnalyzer] Line has trailing whitespace (PSAvoidTrailingWhitespace)". This rule in the script analzyer seems to be extremely unreliable since it's highlighting many lines of code that do not have any trailing or leading spaces - mainly in code that is tab intended or where text strings span across multiple lines (word wrap enabled). Example from a Param section in a custom function:

          [CmdletBinding()]
  Param(
        [ValidateNotNullOrEmpty()][Parameter(Mandatory=$True,Position=1)][string]$ExchangeGuid
  )

The analyzer indicates that the closing parenthesis has trailing whitespace, but it does not. The file is a .ps1 using Windows 1252 encoding and CRLF.

Also disabling this rule via the command palette, PowerShell: Select PsScriptAnalyzerRules doesn’t seem to stay disabled across restarts. Each time I restart VSCode the option is re-enabled. And most of the time I can’t actually load the Select PsScriptAnalyzerRules dialog - it never appears or takes many minutes to appear which is very frustrating.

[rjmholt]

Hi @stukey, for the rule itself you should open an issue in the PSScriptAnalyzer repo.

There is also a way to persist PSSA configurations that @rkeithhill has detailed in #1432 (comment).

It sounds like there are some issues with the Select PSScriptAnalyzerRules dialog:

• It does not persist changes (may be by design, but we might want to change the design?)
• Poor performance (likely related to other performance issues we are currently working on resolving).

[stukey]

Thanks @rjmholt. I will open a separate issue. But I do think that we should be able to persist those rule settings across restarts. The other option of having to create files at the root of each directory seems kinda clunky.

[rkeithhill]

@stukey That's perhaps a personal preference but I certainly prefer having settings like this committed into my SCM system (Git, svn, etc). Ideally, the PSSA UI would act as a UI for this settings file - creating it for you.

[stukey]

@rkeithhill Yep, understood, but we’re not using an SCM currently. Our scripts are stored in numerous folders across multiple servers. So for us the new behaviour is extremely frustrating. Each script we open in VSCode now shows 100s of errors due to the new whitespace rule which we can never resolve or disable.

[rjmholt]

The problem there is that the standard with linters (pyflakes, tslint, hlint, etc.) is to have a configuration file in the code base. The reason that's standard is because linting configurations tend to be per-codebase, not per-user (because multiple users with different linting configurations contributing to the same code would end badly).

But then the extension allows you to override that at runtime as a convenience feature, with the idea in mind that if you want it persisted you write it to the config file.

With all that said... You should be able to configure the "powershell.scriptAnalysis.settingsPath" setting to be any path you like; it will honour an absolute path.

Anyway, I've just noticed that the question about supporting all of this better is better covered by #899.

[SeeminglyScience]

I'd like to see the ability to configure global defaults that take affect only if there is no workspace rule set defined. I also prefer to have the rule set in source control in general, but an untitled workspace or random drafts folder is a pretty common occurrence in PowerShell.

[rkeithhill]

We could have make the PSSA settings be a user/workspace configuration set of settings like the markdown linter uses e.g.:

    "markdownlint.config": {
      "MD024": false
    }

But this has a number of issues. We already have a file for settings - PSScriptAnalyzerSetting.psd1. Having the settings in .vscode\settings.json kind of duplicates the PSSASettings files. Also, PSSA can directly use PSSASettings.psd1 but not .vscode\settings.json. PSSA rules are pretty fluid atm - with new rules being added and existing rules being deprecated (removed). That also presents a challenge for settings persistence. And we have this UI for rule selection that is "in-memory" only. We could make that a UI for editing settings but which settings would we pick - PSSASettings.psd1, workspace settings or user settings?

[bergmeister]

If the extension fixed/implemented #823 then this would make it easier for most users, which is more important than the already referenced #1429

[rjmholt]

Both issues seem pretty straightforward to implement too

[rjmholt]

Yeah I think there are a couple of fairly large design questions here (as in, changing them later will break things), which are:

1. If we persist UI-configured settings, where do we persist them to? Do we overwrite existing settings or do we create a new file?
2. If we allow a second configuration path (e.g. per-user or per-{user+workspace}), what is its precedence wrt a workspace configuration file?

I can see many different valid opinions here and I worry that the more we try to juggle multiple configurations, the more we'll just end up causing pain.

[SeeminglyScience]

PSSA rules are pretty fluid atm - with new rules being added and existing rules being deprecated (removed). That also presents a challenge for settings persistence.

We could kind of get around that by not actually verifying the setting, similar to how feature flags work.

The way I picture it is either

1. Having a setting that is just a list of disabled rules. That makes it easy to disable rules you disagree with (at least in the context of an anonymous workspace), but also makes it so new default rules don't need to be explicitly opt-in. And it'd be dead easy to tie to the UI.

2. Just having a user level setting that specifies a default setting file. This one would allow for more customization, but it would be harder to get started with and harder to tie to the UI.

The way precedence makes sense to me is

• Use the user based setting if no other settings are applied
• If there is a workspace level settings file, discard all user based settings and use the workspace level settings.

Otherwise it'd be too hard to comply with settings vastly different than your own.

[rkeithhill]

Are you not concerned that if the user wants to run PSSA outside of VSCode, PSSA will not be able to use the VSCode settings? This is why I've liked having a PSScriptAnalyzerSettings.psd1 file. You can use it inside VSCode and outside as well.

[SeeminglyScience]

I would still expect workspace settings to be controlled via a the same psd1 file. The only difference is an additional setting that may control the default experience only if the workspace does not have a PSScriptAnalyzerSettings.psd1.