Description
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
- 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
- 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
- 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
- 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 |