GeezerVison

Christoph Bergmeister (@bergmeister) my real concern is the inclusion of this sole rule as an option. Shouldn't we allow any/all the rules to be run?
FWIW - It seems more like the Formatter.Format API is a special instance of the Fix which is perhaps misguided. In the end, It's all corrective measures, some of which are specifically targeting the formatting of the script but we don't have a way to distinguish a formatting change from an actual correction, which is something that RuleInfo should probably have.

Yes, I agree but addressing this technical debt of PSSA's architectural design is non trivial and is a separate issue to me. With this proposed change I'm not adding to the debt.

Yes, I agree but addressing this technical debt of PSSA's architectural design is non trivial and is a separate issue to me. With this proposed change I'm not adding to the debt.

Christoph Bergmeister (@bergmeister) Would you be able to put in one or more issues to fix this particular case of PSScriptAnalyzer's architectural debt? I'd like to take a crack at fixing it myself (or at least jump-start a discussion), considering that I'm looking at extending the PSScriptAnalyzer<=>PowerShellEditorServices interface regarding completions and intellisense sometime over the next few months.

travis-c-lagrone The debt is that the formatter has a list of hard coded rules that it can execute only. As said before, it should be improved so that whilst we might still want to have a hard-coded list of 'default' rules, it would be nice that if one specified any rule in the settings file/object that Invoke-formatter executes them. It would need some research as to why this is the case, I don't know more than that.
With respect to PSSA-PSES integration, the next item on the roadmap is to produce a NuGet package of PSSA so that PSES calls the .NET APIs directly for improved performance (and it also means that PSES can receive updates without requiring PSSA to do a full release.
Some of the other technical debt is the VariableAnalysis classes that were forked from PowerShell's own classes 4 years ago. Those classes were not updated since and have small bugs that leads to certain types of analysis not being possible. Unfortunately, the original maintainers have taken only a subset of it and added a lot of custom code to it. I once tried to just delete it and replace it with the code from PowerShell and some of the challenges were that SMA are very entangled with each other in terms of dependencies and it compiles against .Net Core, but PSSA compiles against .Net Standard...

... I once tried to just delete it and replace it with the code from PowerShell and some of the challenges were that SMA are very entangled with each other in terms of dependencies and it compiles against .Net Core, but PSSA compiles against .Net Standard...

Two questions:

1. By "SMA", do you mean the System.Management.Automation .NET namespace?
2. Is there a particular reason PSSA still supports PowerShell 3? (I ask because it looks like a fair bit of the custom code is because of that) Should PSSA still support PS3 considering that 5.1 is the officially recommended version of WinPS now?

Yes, SMA is System.Management.Automation, which the core part of the PowerShell engine.
We plan to make a major version bump to PSSA 2.0 where support for PS v3/4 gets dropped. Current 'support' is just based on which PS versions are supported by MSFT but dropping support for v3/4 only simplifies some custom code but does not solve the problem with the forked VariableAnalysis code from SMA. We will probably have to support v5.1 for a long time so we will never get around the thing that we do conditional compilation.

When does the PSSA team plan to make the bump to PSSA 2.0? And is there a list of changes somewhere that will/can/should be made concurrently to take advantage of that bump?