The issue was discovered while updating test cases in `rolldown`.
In the `.oxlintignore` file, we have:
```ignore
tests/**
```
When running the command by `lint-staged`:
```bash
oxlint -c .oxlintrc.json --ignore-path=.oxlintignore --deny-warnings "tests/function/main.js"
```
The file `main.js` gets linted despite being ignored. This happens
because, before using `Gitignore::new`, we converted paths to absolute
paths, causing the pattern `tests/**` to not match
`D:/rolldown/tests/function/main.js` correctly.
c61a383e8c/apps/oxlint/src/lint.rs (L60-L78)
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.
- fixes https://github.com/oxc-project/oxc/issues/7365
currently, we are matching globs on the absolute path to the file, which means that in order to properly match, all globs would need to start with `**/`. this is not consistent with the behavior in ESLint, which is defined here: https://eslint.org/docs/v8.x/use/configure/configuration-files#how-do-overrides-work
> **The patterns are applied against the file path relative to the directory of the config file.** For example, if your config file has the path `/Users/john/workspace/any-project/.eslintrc.js` and the file you want to lint has the path `/Users/john/workspace/any-project/lib/util.js`, then the pattern provided in `.eslintrc.js` is executed against the relative path `lib/util.js`.
This PR adds the ability to store the path to the configuration file along with the configuration data, so that we can later use it to resolve the relative paths of the files in the overrides section.
I'm not exactly sure if this will still make sense with nested configuration files, but I think it makes sense to store a path to each configuration file, alongside where the overrides are stored.
It's possible that the rule may not exist at all, or it's part of a
disabled plugin. The help text doesn't give a clue as to which is the
case currently, so it's probably less confusing to just omit it
completely.
- 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.
Continue work on #4742.
Only `oxlint --print-config all` is supported. It's useful to migrate from command-line interface to config file.
The `--print-config PATH` looks not really useful for us now, I will add it after config file overrides supported.
- closes https://github.com/oxc-project/oxc/issues/6038
Migrates all simple iterations over Jest nodes to use the `run_on_jest_node` method. Rules which require more custom data (such as getting nodes in order or storing data about counts, duplicates, etc.) have not been migrated.
Some simple benchmarking shows that this is ~5% faster on `vscode` when the Jest/Vitest rules are NOT enabled (due to being able to skip them now). And it is up to 8% on `vscode` when the Jest/Vitest plugins are enabled.
```
hyperfine -i -N --warmup 3 --runs 30 './oxlint-jest-iter --deny=all --silent ./vscode' './oxlint-main --deny=all --silent ./vscode'
Benchmark 1: ./oxlint-jest-iter --deny=all --silent ./vscode
Time (mean ± σ): 2.348 s ± 0.104 s [User: 16.922 s, System: 0.641 s]
Range (min … max): 2.141 s … 2.544 s 30 runs
Benchmark 2: ./oxlint-main --deny=all --silent ./vscode
Time (mean ± σ): 2.476 s ± 0.042 s [User: 17.768 s, System: 0.668 s]
Range (min … max): 2.430 s … 2.598 s 30 runs
Summary
./oxlint-jest-iter --deny=all --silent ./vscode ran
1.05 ± 0.05 times faster than ./oxlint-main --deny=all --silent ./vscode
```
```
hyperfine -i -N --warmup 3 --runs 30 './oxlint-jest-iter --deny=all --jest-plugin --vitest-plugin --silent ./vscode' './oxlint-main --deny=all --jest-plugin --vitest-plugin --silent ./vscode'
Benchmark 1: ./oxlint-jest-iter --deny=all --jest-plugin --vitest-plugin --silent ./vscode
Time (mean ± σ): 2.728 s ± 0.118 s [User: 19.782 s, System: 0.786 s]
Range (min … max): 2.580 s … 3.078 s 30 runs
Benchmark 2: ./oxlint-main --deny=all --jest-plugin --vitest-plugin --silent ./vscode
Time (mean ± σ): 2.939 s ± 0.051 s [User: 21.259 s, System: 0.859 s]
Range (min … max): 2.848 s … 3.064 s 30 runs
Summary
./oxlint-jest-iter --deny=all --jest-plugin --vitest-plugin --silent ./vscode ran
1.08 ± 0.05 times faster than ./oxlint-main --deny=all --jest-plugin --vitest-plugin --silent ./vscode
```
> Closes#5046
This PR migrates the linter crate and oxlint app to use the new `LinterBuilder` API. This PR has the following effects:
1. `plugins` in oxlint config files are now supported
2. irons out weirdness when using CLI args and config files together. CLI args are now always applied on top of config file settings, overriding them.
# Breaking Changes
Before, config files would override rules set in CLI arguments. For example, running this command:
```sh
oxlint -A correctness -c oxlintrc.json
```
With this config file
```jsonc
// oxlintrc.json
{
"rules": {
"no-const-assign": "error"
}
}
```
Would result in a single rule, `no-const-assign` being turned on at an error level with all other rules disabled (i.e. set to "allow").
Now, **CLI arguments will override config files**. That same command with the same config file will result with **all rules being disabled**.
## Details
For a more in-depth explanation, assume we are running the below command using the `oxlintrc.json` file above:
```sh
oxlint -A all -W correctness -A all -W suspicious -c oxlintrc.json
```
### Before
> Note: GitHub doesn't seem to like deeply nested lists. Apologies for the formatting.
Here was the config resolution process _before_ this PR:
<details><summary>Before Steps</summary>
1. Start with a default set of filters (["correctness", "warn"]) if no filters were passed to the CLI. Since some were, the filter list starts out empty.
2. Apply each filter taken from the CLI from left to right. When a filter allows a rule or category, it clears the configured set of rules. So applying those filters looks like this
a. start with an empty list `[]`
b. `("all", "allow")` -> `[]`
c. `("correctness", "warn")` -> `[ <correctness rules> ]`
d. `("all", "allow")` -> `[]`
e. `("suspicious", "warn")` -> `[ <suspicious rules> ]`. This is the final rule set for this step
3. Apply overrides from `oxlintrc.json`. This is where things get a little funky, as mentioned in point 2 of what this PR does. At this point, all rules in the rules list are only from the CLI.
a. If a rule is only set in the CLI and is not present in the config file, there's no effect
b. If a rule is in the config file but not the CLI, it gets inserted into the list.
c. If a rule is already in the list and in the config file
i. If the rule is only present once (e.g. `"no-loss-of-precision": "error"`), unconditionally override whatever was in the CLI with what was set in the config file
ii. If the rule is present twice (e.g. `"no-loss-of-precision": "off", "@typescript-eslint/no-loss-of-precision": "error"`),
a. if all rules in the config file are set to `allow`, then turn the rule off
b. If one of them is `warn` or `deny`, then update the currently-set rule's config object, but _leave its severity alone_.
So, for our example, the final rule set would be `[<all suspicious rules: "warn">, no-const-assign: "error"]`
</details>
### After
Rule filters were completely re-worked in a previous PR. Now, lint filters aren't kept on hand-only the rule list is.
<details><summary>After Steps</summary>
1. Start with the default rule set, which is all correctness rules for all enabled plugins (`[<all correctness rules: "warn">]`)
2. Apply configuration from `oxlintrc.json` _first_.
a. If the rule is warn/deny exists in the list already, update its severity and config object. If it's not in the list, add it.
b. If the rule is set to allow, remove it from the list.
The list is now `[<all correctness rules except no-const-assign: "warn">, no-const-assign: "error"]`.
3. Apply each filter taken from the CLI from left to right. This works the same way as before. So, after they're applied, the list is now `[<suspicous rules: "warn">]`
</details>
# 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.
## What This PR does
Adds a new `oxc-security/api-key` rule that scans for hard-coded API keys.
It is broken up into "secret rules", where each one is responsible for finding a different kind of key. It is architecturally identical to how lint rules themselves. This PR also includes the first of these rules, for AWS access key IDs.
Logic and rules are based on [keyhunter](https://github.com/Donisaac/keyhunter). I've licensed that repo under GNU GPLv3, but it's my code and I can do what I want with it 😈 (read: I'm fine with it being MIT for oxc).
This PR is a complete feature in its own right, but does not represent the end of this work. See https://github.com/oxc-project/backlog/issues/116 to track overall progress.
> Re-creation of #4427 due to rebasing issues. Original attempt: #642
-----
Third time's the charm?
Each time I attempt this rule, I find a bunch of bugs in `Semantic`, and I expect this attempt to be no different. Expect sidecar issues+PRs stemming from this PR here.
## Not Supported
These are cases supported in the original eslint rule, but that I'm intentionally deciding not to support
- export comments in scripts
```js
/* exported a */ var a;
```
- global comments
```js
/* global a */ var a;
```
## Behavior Changes
These are intentional deviations from the original rule's behavior:
- logical re-assignments are not considered usages
```js
// passes in eslint/no-unused-vars, fails in this implementation
let a = 0; a ||= 1;
let b = 0; b &&= 2;
let c = undefined; c ??= []
```
## Known Limitations
- Lint rules do not have babel or tsconfig information, meaning we can't determine if `React` imports are being used or not. The relevant tsconfig settings here are `jsx`, `jsxPragma`, and `jsxFragmentName`. To accommodate this, all imports to symbols named `React` or `h` are ignored in JSX files.
- References to symbols used in JSDoc `{@link}` tags are not created, so symbols that are only used in doc comments will be reported as unused. See: #4443
- `.vue` files are skipped completely, since variables can be used in templates in ways we cannot detect
> note: `.d.ts` files are skipped as well.
## Todo
- [x] Skip unused TS enum members on used enums
- [x] Skip unused parameters followed by used variables in object/array spreads
- [x] Re-assignments to array/object spreads do not respect `destructuredArrayIgnorePattern` (related to: https://github.com/oxc-project/oxc/issues/4435)
- [x] #4493
- [x] References inside a nested scope are not considered usages (#4447)
- [x] Port over typescript-eslint test cases _(wip, they've been copied and I'm slowly enabling them)_
- [x] Handle constructor properties
```ts
class Foo {
constructor(public a) {} // `a` should be allowed
}
```
- [x] Read references in sequence expressions (that are not in the last position) should not count as a usage
```js
let a = 0; let b = (a++, 0); console.log(b)
```
> Honestly, is anyone even writing code like this?
- [x] function overload signatures should not be reported
- [x] Named functions returned from other functions get incorrectly reported as unused (found by @camc314)
```js
function foo() {
return function bar() { }
}
Foo()()
```
- [x] false positive for TS modules within ambient modules
```ts
declare global {
// incorrectly marked as unused
namespace jest { }
}
```
## Blockers
- https://github.com/oxc-project/oxc/issues/4436
- https://github.com/oxc-project/oxc/issues/4437
- #4446
- #4447
- #4494
- #4495
## Non-Blocking Issues
- #4443
- #4475 (prevents checks on exported symbols from namespaces)
Fix 2 mistakes in the `#[cfg]` for custom allocators in `oxlint` CLI.
1. `#![cfg(not(miri))]` at top of file was disabling the entire module if running miri, rather than just disabling custom allocator.
2. If both `target_os = "windows"` and `not(target_env = "msvc")`, it would try to register both mimalloc and jemalloc as global allocator.
I am actually not sure if it's possible to compile for Windows without using MSVC, but it seems like a good idea not to assume.
This tweaks the conditional compilation of custom allocators by wiring
the dedicated Cargo feature flag `allocator` to the source code. It
ensures that allocator gating is directly checking the relevant feature
instead of trying to infer it from the build profile.
