Description

Issue to track a new feature called Analyzer assists (or actions).

Assists (code actions)

Assists/Action are a concept of the LSP spect. Code actions are usually opt-in, and the user can decide to apply these actions using the UI of a client.

Assists are code actions that can be categorized as refactor opportunities, extractions, etc.

We will borrow this concept and make ours inside the Biome LSP, and we will provide a way to enforce it in the CLI.

Possible configuration:

{
	"assists": {
		"enabled": true, // enables assist across the board
		"enforce": true // the CLI will check if the assists are applied to the source. If not, it fails
	},
	"json": {
		"assists": {
			"useSortKeys": "on" // same naming convention of lint rules, yay!
		}
	},
	"javascript": {
		"assists": { 
			"enabled": false // don't use assists inside javascript files
		}
	}
}

Assists can be opted in from the LSP too. For example, a LSP client can send the following code to enable useSortKeys from the previous example, in VSCode:

{
  "editor.codeActionsOnSave":{
    "source.useSortKeys.biome": "explicit"
  }
}

Or, using zed:

{
  "code_actions_on_format": {
    "source.useSortKeys.biome": true
  }
}

Example of assists:

• #2412
• #2652
• https://github.com/biomejs/biome/discussions/3167

Why not lint rules?

The goal of the Biome linter is to catch possible bugs, enforce some idiomatic coding pattern, or propose some conventions. The Biome linter isn't meant to enforce stylistic decision, because that's what the Biome formatter is meant for.

Why not a formatter?

The Biome formatter is meant to enforce a coding style that matches Prettier as much as possible, and to reduce the diffing inside the PRs. An assists like sorting could have a huge impact on the diffing of PR, that's why assists aren't meant for a formatter.