Provide a way to save rule list selected with "Select PSScriptAnalyzer Rules" menu

[daviwil]

When the user uses the "Select PSScriptAnalyzer Rules" menu we currently don't persist those selections past the current session. We should provide an option in that menu which allows the user to save the current rule selection to a PSScriptAnalyzerSettings.psd1 file in their workspace path.

/cc @mattmcnabb

[rkeithhill]

And optionally create that file if it doesn't exist and wire it up through .vscode\settings.json. Yeah, that'd be nice too.

[daviwil]

Yep, definitely. However, I'd prefer if we could just be smart and detect a PSScriptAnalyzerSettings.psd1 file in the workspace root without the user having to configure it. I think PSScriptAnalyzer does this already but I'm not sure.

[mattmcnabb]

Thanks @daviwil! Weighing out whether I think it would be more valuable as a workspace setting or a user setting, if that's even feasible. Generally I would like the same rules turned on regardless of the project, but I can see how that may not be the right approach.

[rkeithhill]

I'd prefer if we could just be smart and detect a PSScriptAnalyzerSettings.psd1 file in the workspace root without the user having to configure it.

Agreed as long as folks are OK that "by convention" we automatically find a file by that name. BTW is it PSScriptAnalyzerSettings.psd1 or ScriptAnalyzerSettings.psd1? And if the user chooses to use a different name (or location - perhaps in a subdir like src or source), then they'll have to tell us the path to the file.

I also like the idea that the UI mechanism is merely a UI over the corresponding settings file and not another way to manage rules.

Weighing out whether I think it would be more valuable as a workspace setting or a user setting

@mattmcnabb
If you work with more than one open source / GitHub PowerShell module, you'll pretty quickly come to the conclusion that workspace settings is the way to go. A) this file can be checked in and version controlled; B) with "user settings" you're on the hook to make sure the file exists and is configured correctly on multiple machines and C) not every project agrees upon the same settings. :-)

[mattmcnabb]

@rkeithhill I see your point. I think the workspace file would be just fine, and it makes sense to include these settings with a project, to help encourage coding standards for all project contributors. I'm used to flying solo on projects so bad habits prevail ;)

Since I can use a settings file already, the UI itself is not that important to me. For my part, you can keep the menu in place or scrap it altogether. Mainly it just seemed counter-intuitive that the menu changed the settings but did not keep them. Seemed like a breach of contract.

[kevstev01]

Seemed like a breach of contract. +1

[MarcoPeraza]

Just to offer my two cents, while supporting the full config file is good, shouldn't it also be directly exposed through vscode's json settings? The vast majority of users are just going to want to turn one or two checks off (probably PsAvoidUsingCmdletAliases).