Unlike on other OS, on Windows there is no wildcard expansion/globbing
by the shell. Instead the application has to handle this. Therefore I
used the `glob` package to handle wildcards on Windows.
I also had to make the parent directory check more strict due to the
glob package resolving `..` in the middle of the path as well.
This closes#2695.
I should've done a better job at selecting features. Every feature
requires more than just code to get it right.
linting by codeowners' files sounds good on paper but actually not that
useful.
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.
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.
