Psscriptanalyzer: Include CustomRulePath in Settings file

Created on 2 Dec 2016  路  13Comments  路  Source: PowerShell/PSScriptAnalyzer

Currently, the settings file can include on the following keys:

  • IncludeRules
  • 'ExcludeRules'
  • 'Severity`
  • 'Rules`

We would like to add CustomRulePath and IncludeDefaultRules to the settings file so that VSCode users can point to such a settings file and run a custom set of rules while authoring PS scripts.

Area - Documentation

Most helpful comment

@ECNU3D @Ryan2065
Update: This seems to be by design, you need to also specify the -IncludeDefaultRules in this case. The current behaviour is:

  • When CustomRulePath is used (either via command line or settings file), then only the custom rules are going to be used. If you want to ADD the custom rules to the existing default rules, then you need to additionally supply -IncludeDefaultRules
  • When a parameter (CustomRulePath, IncludeRule, etc.) is passed in via the cmdlet, then it overrides its value in the the settings file
  • The behaviour of -IncludeRule is to only include the given rules. When a mix of built in and custom rules should be run then this can be achieved e.g. with the following parameters -IncludeRule @('PSAvoidUsingCmdletAliases','MyCustomRuleStopUsingWriteHost') -IncludeDefaultRules
  • Similarly for -ExcludeRule, one needs the -IncludeDefaultRules when mixing with -CustomRulePath

I agree that the current design does not seem to very intuitive but the current design seems to allow all possible situations.
Therefore the implementation of using CustomRulePath and IncludeDefaultRules seems to be done, but it probably needs better documentation and examples.
Here is an example of a settings file
@{ CustomRulePath='path\to\CustomRuleModule.psm1' IncludeDefaultRules=$true ExcludeRules = @( 'PSAvoidUsingWriteHost', 'PSAvoidGlobalVars' ) }

All 13 comments

Yes please!

What about this demand for evolution ?

We will try to get this thing in in the next couple of releases.

@kapilmb
Hi,
I tried to use CustomRulePath in the setting files, and surprisingly, it works. However, once you used CustomRulePath, your InculdeRules and ExcludeRules setting won't take effect.

Do you have any idea what happened?

I am having the same problem ECNU3D is having. CustomRulePath seems to override IncludeRules and ExcludeRules.

@ECNU3D @Ryan2065
Update: This seems to be by design, you need to also specify the -IncludeDefaultRules in this case. The current behaviour is:

  • When CustomRulePath is used (either via command line or settings file), then only the custom rules are going to be used. If you want to ADD the custom rules to the existing default rules, then you need to additionally supply -IncludeDefaultRules
  • When a parameter (CustomRulePath, IncludeRule, etc.) is passed in via the cmdlet, then it overrides its value in the the settings file
  • The behaviour of -IncludeRule is to only include the given rules. When a mix of built in and custom rules should be run then this can be achieved e.g. with the following parameters -IncludeRule @('PSAvoidUsingCmdletAliases','MyCustomRuleStopUsingWriteHost') -IncludeDefaultRules
  • Similarly for -ExcludeRule, one needs the -IncludeDefaultRules when mixing with -CustomRulePath

I agree that the current design does not seem to very intuitive but the current design seems to allow all possible situations.
Therefore the implementation of using CustomRulePath and IncludeDefaultRules seems to be done, but it probably needs better documentation and examples.
Here is an example of a settings file
@{ CustomRulePath='path\to\CustomRuleModule.psm1' IncludeDefaultRules=$true ExcludeRules = @( 'PSAvoidUsingWriteHost', 'PSAvoidGlobalVars' ) }

Thanks for the time spent reading the code again.
The 'CustomRulePath' key should not be in the plural 'CustomRulesPath'?
{edit]
The name of the key is identical to the parameter name -CustomRulePath ...

It works with VSCode and the command line.
And it also simplifies build scripts

I'm able to populate the powershell.scriptAnalysis.settingsPath to add my own custom rules and use them alongside default rules but if I try to use 'IncludeRule' or 'ExcludeRule' to be selective about default rules then it breaks all Script Analysis in Visual Studio Code. I've tweaked this over the course of a couple weeks and worked backward from examples like the one given by bergmeister (including all properties) but it simply does not seem to work as advertised. I've tried with both PSScriptAnalyzer version 1.16.1 and 1.17.1, and I've been keeping Visual Studio Code for Windows up-to-date (currently at Version 1.24.0).

Can anyone else add custom rules and still pick and choose default rules?

@GFoxHub Yes, I have used setting files that use custom rules but still use either IncludeRule or ExcludeRule but I think the 2 are mutually exclusive because includerules means that PSSA should use only the specified rules but excluderules means that certain rules should be excluded from the total list of default or custom rules.
Have a look at the repo below where i show an example using custom rules and excluderule: https://github.com/bergmeister/PSScriptAnalyzer-VSCodeIntegration
In general I suggest running Invoke-ScriptAnalyzer with the -Verbose switch to see what is going on im case there are parsing/syntax problems

Thanks!! Turns out that I needed to use ExcludeRules instead of ExcludeRule. I figured it would be the latter since that corresponds to the name of the parameter that Invoke-ScriptAnalyzer uses. I even thought that I had tried pluralizing it before, but I probably only tried pluralizing CustomRulePath when I was tinkering with it before.

After you referred me to your repo, I realized that I wasn't following your example code as well as I thought I was.

@GFoxHub Thanks for pointing this out. I did not notice this inconsistency yet and would possibly see this even as a bug although the setting file keys are documented.
I will change it then to allow both the singular and plural version to not introduce a breaking change but avoid that one can fall into this trap. I opened the issue below to track this.

Was this page helpful?
0 / 5 - 0 ratings