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.
