PSSA 2.0 Roadmap

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

从 PSSA 2.0 Roadmap 开始，审阅其中引用的问题，包括 #1480、#1482、#1502、#1484、#1479、#1279、#1483、#1347 和 #1224。只有在一个具体的 roadmap 项目具有明确的范围和实现路径时，贡献才算完成；仅凭此 issue 无法确定文件、测试或入口点。