2 files in AST codegen had Windows-style CRLF line breaks. Change them to Unix-style LF. Does not alter contents of the files aside from the line breaks.
Add a `FIX` constant to `RuleMeta` that describes what kinds of auto
fixes a
rule can perform (if any). This PR also updates `declare_oxc_lint` to
accept a
fix capabilities field. Follow-up PRs in this stack will update existing
rules
and update other parts of the codebase to use this new field.
The end goal of this stack is to
1. automate creation of #4179 in a similar way we auto-update rule
progress,
2. use it in rule documentation pages when we eventually add lint rules
to the website
### TL;DR
Added a `should_run` function to multiple lint rules to determine if a rule should be executed based on the source type. This change optimizes the linting process by avoiding unnecessary rule checks.
### What changed?
1. **New Method**: Introduced the `should_run` method in the `Rule` trait.
2. **Implementation**: Implemented the `should_run` method for various lint rules, particularly those related to React and TypeScript.
3. **Usage**: Updated the `Linter` to use the `should_run` method to filter rules before execution.
4. **Macro Update**: Modified the `declare_all_lint_rules` macro to incorporate the `should_run` method.
### How to test?
1. Run the linter on a project containing React and TypeScript files.
2. Verify that only relevant rules are executed based on the file type (e.g., JSX rules for React files).
### Why make this change?
This change improves the performance of the linter by ensuring that only applicable rules are run for a given file type, reducing unnecessary computation and potential false positives.
---
> 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.
It has the same spirit as #3747 but with a much simpler approach. I've used the fact that @Boshen mentioned about linter always using CFG so now we assert `semantic.cfg().is_some()` in the `LintContext::new` because of this assertion we can have a `LintContext::cfg` that unwraps unchecked.
Eliminates unnecessary checks in our hot paths.
It has the best of both worlds, No complicated typing yet we still get the CFG as a non-optional value without extra ASM or branching.
This PR merges the previous confusing features `serde` and `wasm` into a
single `serialize` feature.
We'll eventually do serialize + type information for both wasm and napi
targets.
`oxc_macros` is removed from `oxc_ast`'s dependency because it requires
`syn` and friends, which goes against our policy ["Third-party
dependencies should be
minimal."](https://oxc-project.github.io/docs/contribute/rules.html#development-policy)
Closes#2641.
Also added `tsify` attribute to the `SerAttrs` derive macro, so `#[cfg_attr(feature = "wasm", tsify(...))]` can also be reduced to `#[tsify(...)]`.
For a various reasons:
This features bloats the code size.
We have many tools for profiling in Rust (as compared to ESLint where the feature came from),
so a built-in feature is not really needed anymore.
ESLint needed `--timings` because it needs to monitor plugins.
We control all our code so we don't need this.
* feat(linter): add restriction category for lint rules
* feat(cli): add "--allow" and "--deny" commands
* feat(linter): use a single instance of linter
* feat(cli): derive rules from args
* feat(cli): print number of rules
