More simplification/preparations for nested configurations:
1. renames `LinterBuilder` to `ConfigStoreBuilder`
2. moves the `options` logic out of `LintBuilder`
3. make `ConfigStoreBuilder::build()` return a result (currently always returns OK, but it will return errors when nested config is implemented
The next steps to implement nested config which i hope to do in the next week are:
1. refactor the `from_oxlintrc` to accept a file path
2. introduce a new method on `ConfigStoreBuilder` (name TBC) that walks all child directories, collecting `.oxlintrc` files. these will be put into `ConfigStore` as a hash map of path > config.
Pure refactor. Re-order imports for clarity:
1. `std`
2. External crates
3. `oxc_*` crates
4. Current crate `use crate::...`
5. Super `use super::...`
6. Local modules
This order is from "furthest away" to "closest". This makes it clearer to see what is coming from where.
`cargo +nightly fmt` (#7877) did a lot of the work, but unfortunately `rustfmt` does not have an option to (a) put workspace crates in a separate block from external crates and (b) move `mod` statements to after `use` statements.
Ref #7456
- Creates a custom action in the language server that applies all
auto-fixes for a given file.
- Updates VS Code to use the custom action with a command to apply fixes
for the currently active text editor.
The parser returns a simple `ModuleRecord` that is allocated in the arena for performance reasons.
The linter uses a more complicated, `Send` + `Sync` `ModuleRecord` that will hold more cross-module information.
The next step is to return more esm information from the parser to eliminated the need of the `oxc_module_lexer` crate.
This could probably use some tests, but I'm not really sure what exactly
should be tested.
Will leave a review with a few comments on things that might need a
different approach.
Closes#7032.
This definitely needs some cleanup by somebody more familiar with Rust,
but I think it contains most of the important pieces. I'll leave a
review with the different pieces that I know need cleanup.
Ref #6966.
closes#7434
i couldn't test this. but what's happening is semaitc is being build
without scope child ids. When exhaustive_deps tries to access it its an
empty vec - hence the panic
- closes https://github.com/oxc-project/oxc/issues/6988
we now return an error exit code when there are unmatched rules. previously, we would print an error to stderr and continue running. however, this masked errors in some tests that actually had unmatched rules in them. these test cases now trigger a panic (in tests only, not at runtime), and help ensure that we are reporting an error message to the user for unknown rules, which we did not have any tests cases for before.
- fixes https://github.com/oxc-project/oxc/issues/7025
this also fixes https://github.com/oxc-project/oxc/issues/7025, where we were reporting rules as unmatched simply because they had been disabled prior to being configured. similar to https://github.com/oxc-project/oxc/issues/7009.
- fixes https://github.com/oxc-project/oxc/issues/5913
This PR fixes the calculation of spans when dealing with files that have multiple sources and non-zero source start offsets. This is almost always the case for `.vue`, `.astro`, and `.svelte` files. This enables us to correctly apply fixes for these file types both in the CLI with `oxlint` and also in editors like VS Code.
https://github.com/user-attachments/assets/2836c8bd-09be-4e59-801d-7c95f8c2491f
I'm open to ideas on how to improve testing in this area, as I don't think that we currently have any tests for fixing files end-to-end (beyond what the linter rules check). I did run this locally on the gitlab repository (which is written in Vue) and all of the fixes appeared to be applied correctly.
# Human Description
Low on time, so this one is short.
- consolidate source file and partial loader logic into `loader` module. I have more plans for this.
- ~LSP no longer uses `VALID_EXTENSIONS`, so now `.d.ts` files (and the like) will be linted as well~ LSP does not respect `.gitignore` files, so this change was reverted.
# AI Description
## Refactor Loader and Partial Loader
This PR refactors the loader and partial loader functionality in the oxc_linter crate:
* Introduce a new `Loader` struct with methods for checking if a file can be loaded and loading file contents
* Move `partial_loader` module to `loader/partial_loader`
* Rename `JavaScriptSource` to `source.rs` and move it to the `loader` module
* Update `JavaScriptSource` to use `u32` for `start` offset instead of `usize`
* Refactor `IsolatedLintHandler` to use the new `Loader`
* Update imports and module references throughout the codebase
This change improves the organization of the loader-related code and provides a more unified interface for loading different file types.
Realized we can get the source type from the AST.
The next PR will introduce `unambiguous` to `SourceType` and directly set `Program::source_type` to either `script` or `module`.
> 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.
