PSSA 2.0 Roadmap

[SydneyhSmith]

Note: this is meant to be a living artifact for discussing, and tracking the 2.0 milestone

PSSA 2.0 Roadmap

PSScriptAnalyzer 2.0 is a major architecture of the PSScriptAnalyzer (PSSA) module, a static code checker for PowerShell modules and scripts which provides linting and formatting for PowerShell Editor Services.

Motivation

The goals and uses of PSSA have evolved since the module was first developed as a prototype in 2015. The heavy use of the module in PowerShell Editor Services mean that embeddability and interuptability are new priorities. This integration scenario also amplifies the benefit of gains made to the performance and stability of the module.

As we continue to ship new versions of PowerShell across many platforms, the number of possible version and platform targets multiplies.
Therefore it is a growing priority to supplement these PowerShell releases with tooling that allows for script migration, as well as targeted authoring to specific PowerShell versions ands platforms.
This compatibility framework allows module authors to contribute the PowerShell ecosystem while still being able to target users who may be on other versions of PowerShell or develop on other platforms.

The role of PSSA in CI/CD pipelines presents a priority for better custom rule customization and configuration.
The integration point of PSSA in Visual Studio Code provides opportunities for reliable, customizable rule configuration (and authoring) in a familiar interface.

Because of constraints in the current design of this module, the most efficient way to maximize these improvements to the module are through a re-architecture of the module.
This approach allows us to optimize the way PSSA works (rule metadata, how PowerShell engine is called etc.) as a core components of improving the end user experience.

Goals

1. Improved performance and stability, especially for the VSCode extension

• Top priority is formatting rules
• Next target is for current 5 slowest rules which generate the bottleneck
• Goal is to reduce the number of passes through the PowerShell parser, and the need to generate instances of PowerShell

2. PSSA can be easily integrated into other applications (embeddability)

• PSSA can be read in a thread safe way with or without PowerShell
• Top embeddability scenario is editor services
• Next target scenario is CI/CD systems

3. Compatibility rules are easy to create, configure, and run.

• Simplified process for installing profiles and naming conventions
• Improving this experience is partially reliant on easier generation of profiles

4. Rule customization (users writing their own rules) and configuration (for built in and custom rules) should be straightforward, reliable, and consistent

• Rules are written in C# and PS Script and configured with JSON
• Easier targeting for rule suppression (within code—comment based, within workspaces, and globally)
• Rules can be packaged and shared as nuget packages or modules

Stretch goal

As a PowerShell user I only need the latest version of PowerShell on my dev box regardless of platform or PowerShell version I will eventually deploy my script on.

Scenarios and Issues

High Level Scenario	Sub Scenario	Implementation notes	Issues	Status
Improved performance and stability, especially for the VSCode extension	Performance of Formatting Rules	Formatter should be run in parallel	#1480	Not Started
				Not Started
	Target speed of Five Slowest Rules	Reduce/Cache calls to Get-Command: Slow rules are because of Get-Command calls		Not Started
		Optimize cache with consideration to speed and memory (consider a two-level cache)		Not Started
		Improve how the cache is queried		Not Started
	Reduce the number of passes through the PowerShell parser			Not Started
	Reduce the need to generate instances of PowerShell	Better rule meta-data (clear rule types: formatting, diagnostic; needs PowerShell vs doesn’t)		Not Started
PSSA can be easily integrated into other applications (embeddability)	PSSA can be read in a thread safe way with or without PowerShell			Not Started
	PSSA as a standalone executable	Analysis as a service		Not Started
	PSSA can be well integrated with editor services	Async analysis (interuptability is key)	#1482	Not Started
		Better Rule APIs		Not Started
		Support running in constrained language mode	#1502	Not Started
		Intellisense support for rule configuration		Not Started
	PSSA can be well integrated within CI/CD			Not Started
Compatibility rules are easy to create, configure, and run	Simplified process for installing profiles and naming conventions	Easier language version targets/parser integration	#1484	Not Started
	Easy generation of compatibility profiles			Not Started
Rule customization (users writing their own rules) and configuration (for built in and custom rules) should be straightforward, reliable, and consistent	Rules are written in C# and PS Script			Not Started
	JSON for configuration		#1479, #1279	Not Started
	Easier targeting for rule suppression (within code—comment based, within workspaces, and globally)		#1483, #1347	Not Started
	Rules can be packaged and shared as nuget packages or modules			Not Started
	Proper global settings		#1484, #1224	Not Started
General User Experience	Clear documentation		#1487	Not Started
	Robust testing		#1488	Not Started
	Performance testing?			Not Started
	Stress testing?			Not Started

[fflaten]

Any update on the ETA for this major release?

Fall 2020 is the last I've seen mentioned.

[fflaten]

Any update? ETA? @bergmeister @SydneyhSmith

[StevenBucher98]

@fflaten no current eta at this time, we are currently investing in other areas at the moment.

[iRon7]

Is there any update on this?
We are currently dealing with a performance issue in our street, see: #1484 (comment)

[bergmeister]

I don't think so although I cannot speak for PS team. Your referenced issue is isolated to the workings of compatibility rules and not related to PSSA rewrite