oxc/crates/oxc_language_server at cbf08d276172285dfd7f00a57b13ee7f2fb65359 - dan/oxc

dan/oxc

mirror of https://github.com/danbulant/oxc synced 2026-05-21 21:29:01 +00:00

History

DonIsaac 7a75e0f8a7 refactor(linter): use diagnostic codes in lint rules (#4349 ) > This PR is (unfortunately) quite large, but all changes are needed in tandem for this to work properly. ## What This PR Does Updates the linter to populate diagnostics reported by rules with error codes statically derived from `RuleMeta` + `RuleEnum`. Doing so required changing how we handle vitest rules. I know @mysterven was hoping to refactor that part of the code, and I think this approach is an improvement (but could probably be cleaned up further). ## Changes ### 1. Auto-Populate Error Codes `LintContext` now sets an error code scope + error code number for diagnostics reported by lint rules. `LintContext` will not clobber existing codes set by rules, allowing for rule-specific override behavior (e.g. to use `eslint-plugin-react-hooks` as an error scope). In order to accomplish this, I had to update every diagnostic factory for every rule. While doing this I found some incorrect error messages, or messages that could be easily improved. This is where a large majority of the snapshot diffs come from. Additionally, I was able to reduce string allocations from `format!` usages in diagnostic factories, especially within jest rules. ### 2. Framework and Library Detection This PR adds `FrameworkFlags`, which specify what (if any) set of libraries and frameworks are being used by a project and/or file. They are passed in two ways: 1. `LintOptions` can specify a set of `framework_hints` that apply to the entire target codebase. Right now these are always empty, but I'm thinking in the future we could sniff `package.json`. It may be helpful for enabling/disabling default rules. 2. When `Linter` gets run on a file, framework information is sniffed from the `LintContext`. Right now, we are only checking for `vitest` imports in `ModuleRecord` and test path prefixes from `source_path`. It may be useful to do something similar for React/NextJS rules in the future. I know that [next/no-html-link-for-pages](https://nextjs.org/docs/messages/no-html-link-for-pages) could benefit greatly from this.	2024-07-20 03:35:00 +00:00
..
src	refactor(linter): use diagnostic codes in lint rules (#4349 )	2024-07-20 03:35:00 +00:00
Cargo.toml	chore: turn off doctest for all [[bin]]	2024-07-14 16:55:19 +08:00

DonIsaac 7a75e0f8a7 refactor(linter): use diagnostic codes in lint rules (#4349 )

> This PR is (unfortunately) quite large, but all changes are needed in tandem for this to work properly.

## What This PR Does

Updates the linter to populate diagnostics reported by rules with error codes statically derived from `RuleMeta` + `RuleEnum`.

Doing so required changing how we handle vitest rules. I know @mysterven was hoping to refactor that part of the code, and I think this approach is an improvement (but could probably be cleaned up further).

## Changes

### 1. Auto-Populate Error Codes
`LintContext` now sets an error code scope + error code number for diagnostics reported by lint rules. `LintContext` will not clobber existing codes set by rules, allowing for rule-specific override behavior (e.g. to use `eslint-plugin-react-hooks` as an error scope).

In order to accomplish this, I had to update every diagnostic factory for every rule. While doing this I found some incorrect error messages, or messages that could be easily improved. This is where a large majority of the snapshot diffs come from. Additionally, I was able to reduce string allocations from `format!` usages in diagnostic factories, especially within jest rules.

### 2. Framework and Library Detection
This PR adds `FrameworkFlags`, which specify what (if any) set of libraries and frameworks are being used by a project and/or file. They are passed in two ways:

1. `LintOptions` can specify a set of `framework_hints` that apply to the entire target codebase. Right now these are always empty, but I'm thinking in the future we could sniff `package.json`. It may be helpful for enabling/disabling default rules.
2. When `Linter` gets run on a file, framework information is sniffed from the `LintContext`. Right now, we are only checking for `vitest` imports in `ModuleRecord` and test path prefixes from `source_path`. It may be useful to do something similar for React/NextJS rules in the future. I know that [next/no-html-link-for-pages](https://nextjs.org/docs/messages/no-html-link-for-pages) could benefit greatly from this.

2024-07-20 03:35:00 +00:00

src

refactor(linter): use diagnostic codes in lint rules (#4349 )

2024-07-20 03:35:00 +00:00

Cargo.toml

chore: turn off doctest for all [[bin]]

2024-07-14 16:55:19 +08:00