Repository navigation
Provide a way to save rule list selected with "Select PSScriptAnalyzer Rules" menu #823
Description
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.
Reacted by Matt McNabb, jabbahudson, Michael Klement, Kevin Stevens, David Faivre, Saul Ansbacher and Doug Bailey
Activity
rkeithhill commentedon Jun 2, 2017
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 commentedon Jun 2, 2017
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 commentedon Jun 2, 2017
Thanks David Wilson (@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 commentedon Jun 4, 2017
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.
Matt McNabb (@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 commentedon Jun 5, 2017
Keith Hill (@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 commentedon Feb 5, 2020
Seemed like a breach of contract. +1
MarcoPeraza commentedon Jun 2, 2020
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).