Fix a bug introduced in https://github.com/oxc-project/oxc/pull/1966.
Ideally, the rules in eslintrc should be merged into final rules as
described:
> The rules will start with the categories we apply, and then merge all
the configurations stated in the rules field.
>
> For example, if we begin with -D correctness with 80 rules, then
>
> "no-empty-file": "off" will remove the rule, yielding 79 rules
> "no-empty": "error" (restriction) will add the rule, yield 81 rules
> ""no-empty": ["error", { "allowEmptyCatch": true }]` add the rule's
configuration
However, the implementation did not include the newly added rules in the
eslintrc. As a test case and example, I added a new fixture to
`crates/oxc_cli/fixtures/no_undef`. No warn or deny will be found
without this PR.
This is my first Rust PR ever. Any nitpicking suggestions are welcome.
Thanks! 😊
Previously if .eslintrc.json contains
```
{
"rules": {
"no-empty": "off"
}
}
```
Then no rules will be enabled.
---
This PR changes how we configure oxlint's rules.
The rules will start with the categories we apply, and then merge all
the configurations stated in the `rules` field.
For example, if we begin with `-D correctness` with 80 rules, then
* `"no-empty-file": "off"` will remove the rule, yielding 79 rules
* `"no-empty": "error"` (restriction) will add the rule, yield 81 rules
* ""no-empty": ["error", { "allowEmptyCatch": true }]` add the rule's
configuration
As discussed in #1124
A common workflow is running `oxlint` automatically via something like
lint-staged, which passes all changed file paths explicitly as CLI
arguments. The ignore crate auto-whitelists explicit paths, overriding
anything defined in an ignore file, leading to files that should be
ignored causing CI and VC hooks to fail.
eslint avoids this issue by giving precedence to .eslintignore unless
you pass `--no-ignore`.
Since `ignore` doesn't really give much control over this, the most
effective solution seems to be filtering. ~~Once we've got a list of
files to be linted, we can compare each against the .eslintignore and
see if it really truly should be linted.~~
~~Unfortunately, this is sort of a naive solution. Ignored directories
will still be walked, then filtered out after the fact. Changing this
behavior at the walker level would affect the formatter, which probably
isn't desirable.~~ (edit: The performance impact has been mostly
resolved.)
Signed-off-by: Clark Fischer <clark.fischer@gmail.com>
not sure if there is a cleaner way to do this.
maybe change `check_options` to return an Option - none if no CliResult, Some if there is a cli result (something was incorrect or the cmd was handled)
**DRAFT**
Adds support for parsing `eslint` configuration files.
Example:
```sh
cargo run --bin=oxc_cli lint --config-path ./.eslintrc.json .
```
This isn't a full implementation of how eslint parses configs but should
be fine for now:
Currently supported `extends`:
- `eslint:recommended` -> `eslint`
- `plugin:react/recommended` -> `react`
- `plugin:@typescript-eslint/recommended` -> `typescript`
- `plugin:react-hooks/recommended` -> `react`
- `plugin:unicorn/recommended` -> `unicorn`
- `plugin:jest/recommended` -> `jest`
These defaults can _all_ be overridden by configuring the rule in the
`rules` section of the estlint config:
e.g.
```json
{
"extends": [
"eslint:recommended"
],
"rules": {
"eqeqeq": "off"
},
}
```
This would enable of of the rules within the `eslint` group. But would
not enable `eqeqeq` as it is explicitly disabled
Note, we do not currently support the following:
- supplying a `filter` and `config-path`
- supplying a `plugin` and `config-path`
See #1403
Terminates linting with an exit code of 1 if the `--deny-warnings` flag
is provided _and_ there is 1 or more warnings produced from the linting.
`oxlint --max-warnings 99999` should exit with success status code when
there are warnings but no errors found. Currently any warning or error
results in an exit status of 1.
