Enable script-based rules to be contributed to the core ruleset

[daviwil]

Just opening up this issue to track the need for this. @ThmsRynr has a few rules he'd like to contribute so we'll need to make it possible for his rules and more like them to be contributed.

[bergmeister]

@ThmsRynr I have a prototype in my branch here that makes this work for the CommunityAnalyzerRules only (due to a hard-coded folder name as a PoC ) if you copy the CommunityAnalyzerRules folder into a folder named ScriptRules into the PSSA module installation directory (i.e. something like C:\Program Files\WindowsPowerShell\Modules\PSScriptAnalyzer\1.16.1\ScriptRules).
As expected, it has a bad performance hit. Whenn running it against simple one-liners, execution time (after JITTING/warmup but the factor are similar when running the command for the first time) increased from around 80 ms to 350ms and executing the entire test suite increases from 2 to 5 min.
Could you give a link to the rules that you would like to contribute? Depending on how complex they are, it might be better to just rewrite them in C#.

[bergmeister]

@ThmsRynr I discussed this with Steve Lee (@SteveL-MSFT) at psconf.eu. We either need to either provide a way of optionally running script base rules or translate the rule into C# for performance reasons. Could you provide some examples of the rules that you would like to contribute?

[thomasrayner]

Hey, Christoph Bergmeister (@bergmeister) . As I continue to get deeper into writing PSSA rules myself, I'm growing increasingly willing to write them in C#, but I'm just one case. I'm sure there are lots of awesome rules or contributions waiting to be made by people who are PowerShell people but aren't willing to learn C#.

I've got a modest repo of custom PSSA rules that I'd consider proposing, written in PowerShell. https://github.com/ThmsRynr/CustomPSSARules

Some of them are more deserving of consideration than others, and some could use some polishing. The ones that make the most sense are probably in the Casing folder.

[SteveL-MSFT]

I think what we could do is make running script based rules opt-in. We should still take contributions that are in PowerShell Script, but I'm hoping the community can help converting popular rules to C# over time.

[thomasrayner]

That sounds like a pretty reasonable compromise, Steve Lee (@SteveL-MSFT). When the issue was originally opened, I don't think we anticipated the size of the performance impact of running PowerShell-based rules. The idealist in me wants to reply with something about addressing the performance impact but I know it's not likely a PSSA issue, and it's probably not worth tackling even if it was.

Clearly this is a big conspiracy to force me to start writing C# again. Looking forward to getting back into some C#!

[iRon7]

The way I would like to see something like this request to be implemented, is simply being able to use Install-Module or Install-PSResource to install the (PowerShell-based) rule into the PSScriptAnalyzer:

Technically:

When every the PSScriptAnalyzer module initializes, it checks the $Env:PSModulePath for modules/rules (as PowerShell does) that follow specific requirements, like:

• The name of the module/rule name <ruleName>.PSRule\<version>\<ruleName>.PSRule.psm1 (e.g.: PSAvoidUsingNewObject.PSRule\<version>\PSAvoidUsingNewObject.PSRule.psm1)
  • Possibly with a specific additional .psd1 file
• And that the script block contents includes items (based on Creating custom rules), as:
  • function <ruleName> (e.g.: function PSAvoidUsingNewObject)
  • [OutputType([Microsoft.Windows.PowerShell.ScriptAnalyzer.Generic.DiagnosticRecord])]
  • Export-ModuleMember -Function Measure-<ruleName> (e.g.: Export-ModuleMember -Function Measure-PSAvoidUsingNewObject)

When the conditions are met, simply adopt the (PowerShell-based) rule into the current PSScriptAnalyzer ...