Feature request : Add the possibility to load custom rules by a module name or a fully qualified name

[LaurentDardenne]

Today if i publish custom rules, i use a module, but PSScriptAnalyzer need a path to load these custom rules.
I can write this:

$Path=(Import-Module ParameterSetRules -pass).Modulebase
Invoke-ScriptAnalyzer -CustomRulePath $Path

Here this code is not dependent to a path :

Invoke-ScriptAnalyzer -CustomRuleModule ParameterSetRules 
#or 
Invoke-ScriptAnalyzer -CustomRuleModule @{ RootModule = 'ParameterSetRules';ModuleVersion = '1.0'; GUID = 'a5d7c151-56cf-40a4-839f-0019898eb324' }

[LaurentDardenne]

Will this request be taken into consideration?
This would simplify the use of configuration file:

@{
    CustomRulePath=@('C:\Program Files\WindowsPowerShell\Modules\ParameterSetRules\1.0.0\ParameterSetRules.psd1','C:\Program Files\WindowsPowerShell\Modules\OptimizationRules\0.3.0\OptimizationRules.psd1')
    IncludeDefaultRules=$true
}

Today if I change the version of one of these modules, I have to modify the configuration file.
And that for each project using these same external rules

[bergmeister]

Although a -CustomRuleModule option would add yet another parameter, it seems reasonable to have such a feature. If this issue is important to you, I think you can go ahead with a PR. cc @JamesWTruher

[LaurentDardenne]

if this issue is important to you

For those who use external rules encoded powershell.
I will continue to use a bypass (I adapt to the problem).

In my opinion, this discussion will sooner or later come up against this limit.

[bergmeister]

@LaurentDardenne Interesting. My thinking is:
If rules are generic, then they should be part of the core ruleset (and therefore converted to c# for performance/maintenance/versioning reasons), therefore i do not see the link to the other discussion.
However, I can imagine a world where e.g. the AzureRm module provides a PSSA module with custom rules to warn about deprecated cmdlets/parameters or undesired patterns and people would just configure PSSA to use this external PSSA extension module. I would even take it one step further and let Invoke-ScriptAnalyzer auto-discover such modules by looking e.g. for a special PSSA tag in the module manifest.
What do you think?

[LaurentDardenne]

i do not see the link to the other discussion.

Perhaps a problem of language comprehension on my side, the title seemed clear to me:
'Enable script-based rules to be contributed to the core ruleset'
For 'script-based rules' I understand Powershell script :

(get-module ParameterSetRules).ModuleType
#Script

Or is it to prototyping?

I would even take it one step further and let Invoke-ScriptAnalyzer auto-discover such modules by looking e.g. for a special PSSA tag in the module manifest.

Plaster does that and it's a appreciable behavior. For PSSA I prefer a configuration file.
To facilitate the search for rule modules would be helpful, I agree.

What do you think?

Personally before seeing further I would like to see the correction of some bugs which, for me, limit the use of script-based rules or ask me 'more' effort to use it.

[bergmeister]

The big difference to including script based rules as part of PSSA itself as part of the default rules has a significant performance impact as I showed in my proof of concept. Hence why I'd rather like to convert them to c#.
Any rule that is not generic to PowerShell itself and useful to everyone should rather be optional via referencing a 3rd party module (no matter if the rule is written as a script or .net dll). Of course one could also include optional rules in PSSA itself and have a PSSA setting for using it but then the versioning and maintenance of those optional rules are tied to PSSA. Similar to PowerShell itself, PSSA should be just the engine itself with a base set of rules that are useful to everyone.
To summmarize:
I think this issue is useful to improve extensibility by just providing the name of the locally installed module containing additional rules that extend PSSA instead of a hard-coded path in the settings file. Independent versioning (i.e. fixing a bug in the rule itself or adding new rules at any time without being dependent on PSSA releases) is the main reason.
If someone has something generic then I'm happy to look at converting it to C# and include it in the default ruleset of PSSA.
Does that make sense and would you be happy with that? Cc @SteveL-MSFT
After the release I plan to look into the multi-threading issues and internal testing problems with PowerShell Core and AppVeyor. I could also look into this issue then. As usual I try to provide quick-fixes for more recent issues like the one for Nano-Server. As I said: With Open-Source you are only guaranteed to get what you do yourself, hence why I encourage you to contribute as well, a lot of my PSSA work is done in my spare time, therefore I also have to pick things that are useful or at least interesting to myself but as I did it in the past, I am happy to help out in the community with contributions.
In general, a community call would be interesting to know which issues are important to the community to be able to prioritize the right things. Could you list the top 3-5 issues in descending priority for you please?

[LaurentDardenne]

@bergmeister sorry for the late response.

I think this issue is useful to improve extensibility by just providing the name of the locally installed module containing additional rules that extend PSSA instead of a hard-coded path in the settings file. Independent versioning (i.e. fixing a bug in the rule itself or adding new rules at any time without being dependent on PSSA releases) is the main reason.
If someone has something generic then I'm happy to look at converting it to C# and include it in the default ruleset of PSSA.
Does that make sense and would you be happy with that?

Yes I does.

[LaurentDardenne]

Could you consider these points in version 2.0 of PSSA ?

[bergmeister]

Yes, similar points have been brought up to improve the experience the way custom rules integrate into PSSA. cc @rjmholt