windows will fail, looks like the offset missmatch is because of `\r\n`
vs `\n`.
```
Snapshot file: apps\oxlint\src\snapshots\--format=json test.js@oxlint.snap
Snapshot: --format=json test.js@oxlint
Source: C:\dev\oxc:74
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────-old snapshot
+new results
────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 0 0 │ ##########
1 1 │ --format=json test.js
2 2 │ ----------
3 3 │ [
4 │- {"message": "`debugger` statement is not allowed","code": "eslint(no-debugger)","severity": "error","causes": [],"url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-debugger.html","help": "Delete this code.","filename": "test.js","labels": [{"span": {"offset": 38,"length": 9}}],"related": []},
4 │+ {"message": "`debugger` statement is not allowed","code": "eslint(no-debugger)","severity": "error","causes": [],"url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-debugger.html","help": "Delete this code.","filename": "test.js","labels": [{"span": {"offset": 42,"length": 9}}],"related": []},
5 5 │ {"message": "Function 'foo' is declared but never used.","code": "eslint(no-unused-vars)","severity": "warning","causes": [],"url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-unused-vars.html","help": "Consider removing this declaration.","filename": "test.js","labels": [{"label": "'foo' is declared here","span": {"offset": 9,"length": 3}}],"related": []},
6 6 │ {"message": "Parameter 'b' is declared but never used. Unused parameters should start with a '_'.","code": "eslint(no-unused-vars)","severity": "warning","causes": [],"url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-unused-vars.html","help": "Consider removing this parameter.","filename": "test.js","labels": [{"label": "'b' is declared here","span": {"offset": 16,"length": 1}}],"related": []}
7 7 │ ]
────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────To update snapshots run `cargo insta review`
Stopped on the first failure. Run `cargo insta test` to run all snapshots.
thread 'output_formatter::test::test_output_formatter_diagnostic_json' panicked at C:\Users\sysix\.cargo\registry\src\index.crates.io-6f17d22bba15001f\insta-1.42.0\src\runtime.rs:679:13:
snapshot assertion for '--format=json test.js@oxlint' failed in line 74
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- output_formatter::test::test_output_formatter_diagnostic_stylish stdout ----
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Summary ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Snapshot file: apps\oxlint\src\snapshots\--format=stylish test.js@oxlint.snap
Snapshot: --format=stylish test.js@oxlint
Source: C:\dev\oxc:74
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────-old snapshot
+new results
────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 3 3 │
4 4 │ ␛[4mtest.js␛[0m␊
5 5 │ ␛[2m9:3 ␛[0m ␛[33mwarning␛[0m Function 'foo' is declared but never used. ␛[2meslint(no-unused-vars)␛[0m␊
6 6 │ ␛[2m16:1␛[0m ␛[33mwarning␛[0m Parameter 'b' is declared but never used. Unused parameters should start with a '_'. ␛[2meslint(no-unused-vars)␛[0m␊
7 │- ␛[2m38:9␛[0m ␛[31merror␛[0m `debugger` statement is not allowed ␛[2meslint(no-debugger)␛[0m␊
7 │+ ␛[2m42:9␛[0m ␛[31merror␛[0m `debugger` statement is not allowed ␛[2meslint(no-debugger)␛[0m␊
8 8 │
9 9 │ ␛[31m✖ 3 problems (1 error, 2 warnings)␛[0m
────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────To update snapshots run `cargo insta review`
Stopped on the first failure. Run `cargo insta test` to run all snapshots.
thread 'output_formatter::test::test_output_formatter_diagnostic_stylish' panicked at C:\Users\sysix\.cargo\registry\src\index.crates.io-6f17d22bba15001f\insta-1.42.0\src\runtime.rs:679:13:
snapshot assertion for '--format=stylish test.js@oxlint' failed in line 74
failures:
output_formatter::test::test_output_formatter_diagnostic_json
output_formatter::test::test_output_formatter_diagnostic_stylish
test result: FAILED. 85 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.12s
```
This is needed so we can use a custom `Write` implementation (or just `[u8]`) to make snapshots.
In this step I also updated `OutputFormatter::all_rules` so the Formatter does not need to handle the write-error.
Now every lint output is owned by is right OutputFormatter and his DiagnosticReporter 🥳
Next step is to setup a snapshot Tester, so I can remove the ToDos.
Reorded some lines so the outfor is now for: `cargo run -p oxlint -- test.js --max-warnings=2`
```
Found 4 warnings and 0 errors.
Exceeded maximum number of warnings. Found 4.
Finished in 5ms on 1 file with 97 rules using 24 threads.
```
and for `cargo run -p oxlint -- test.js`
```
Found 4 warnings and 0 errors.
Finished in 5ms on 1 file with 97 rules using 24 threads.
```
The output time and warnings/error count wil be always printed.
We are currently outputting only for the default-outputter some extra
information:
3be03926e8/apps/oxlint/src/result.rs (L61-L87)
My goal is that all information will be passed to our new
DiagnosticReporter / OutputFormatter.
This will break the output format in the next PR. **Merging this PR is
the OK for me to make this change** ⚠️
The only breaking point:
`"Found {number_of_warnings} warning{} and {number_of_errors} error{}."`
will still be outputted when `max_warnings_exceeded` is true.
Because this is something the `DiagnosticReporter` should do and not the
`OutputFormatter`.
The end goal is:
- no `println!`, our `OutputFormatter` and his `DiagnosticReporter` will
return `Option<String>` and we output it the our `stdout`
- `LintResult` will only handle `ExitCode` result and nothing more
- `stdout` can be changed from outside (for the next part)
- add snapshots with a custom `stdout`
I do not know if all goals can be done easily. Last two parts should be
a bit tricky for me, never did test setups in rust.
But we do never stop to learn ;)
The $schema property was not added when the --init command was used to
create the configuration. Now, $schema is added based on the
availability of configuration_schema.json in the current working
directory.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
👋 This implements a reporter for `--format` on `oxlint` which aims to be
visually similar to
https://eslint.org/docs/latest/use/formatters/#stylish
Please note that this is my first time working with Rust and my
knowledge is very limited. I'm unlikely to understand best-practice or
best-pattern references outside of what clippy/cargo lint has already
had me change. If this needs modification, please help me out by making
code suggestions that can be merged to this PR.
Resolves#8422
---------
Co-authored-by: Cameron <cameron.clark@hey.com>
it was never the plan that oxc_diagnostics should be the
`std::io::stdout` writer:
8fc238ac34/crates/oxc_diagnostics/src/service.rs (L84-L85)
This PR does refactor all reporters to `oxlint` crate and make the
current implementation of `oxc_diagnostics` public for others to
consume.
I added some tests to reflect to expected output (and found some bugs^^)
For the future I think the BufWriter for `std::io::stdout` should come
from outside.
Or maybe `std::fmt::stdout`? I do not know^^"
I could not test 100% of the code, I hope I can fix this with the next
PR which will include a own Tester for oxlint (like `oxc_linter`).
Please be extra careful when reviewing it.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## [0.15.6] - 2025-01-13
### Features
- 457aa31 linter: Implement `no-lone-blocks` rule (#8145) (Yuichiro
Yamashita)
### Refactor
- aea9551 ast: Simplify `get_identifier_reference` of `TSType` and
`TSTypeName` (#8273) (Dunqing)
- 43ed3e1 linter: Add output formatter (#8436) (Alexander S.)
- 4e05e66 linter: Remove glob for windows (#8390) (Alexander S.)
- b19d809 linter: Split `unicorn/prefer-spread` and
`eslint/prefer-spread` into own rules (#8329) (Alexander S.)
- 3c534ae linter: Refactor `LintBuilder` to prep for nested configs
(#8034) (camc314)
- 2f9fab9 linter: Remove remapping for plugin name in diagnostics
(#8223) (Alexander S.)
### Testing
- b6c1546 linter: Use plugin name instead of category for finding rule
(#8353) (Alexander S.)
Co-authored-by: Boshen <1430279+Boshen@users.noreply.github.com>
I want to start grouping all the different Formats for action X, Y and Z
into own place.
This is the first step and probably not the best one to be honest :)
~~I prefer that the `OutputFormatter` is a part of `oxlint` and not
`oxc_linter`~~
~~but all `use create::rules::RULES` is not public from outside.~~
EDIT: I pushed a commit with this changes can easily be reverted and
move back to `oxc_linter`
Also their is a crate `oxc_diagnostics` which has already the concept
too but only for the lint part of `oxlint` and not for the other parts.
The next goal would be splitting the `DiagnosticService` with its
reporters to `oxlint`.
The current implementations does not work. Under linux it tells me 0
files, under windows:
```
> oxc-vscode@0.15.5 lint C:\dev\oxc\editors\vscode
> npx oxlint --config=oxlint.json --tsconfig=tsconfig.json client/*.js
Finished in 5ms on 5 files with 101 rules using 24 threads.
Found 0 warnings and 0 errors.
```
I do not think this glob is needed. we are using `ignore` in our
`Walker`, which should already covering the use case.
---------
Co-authored-by: Sysix <alexander.schlegel@clicksports.de>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
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.
Changes:
- Config `ignorePatterns` not as `Path`, because the create `ignore`
does only handle `/` and not Win-style `\`
- Passed full path to the config and do not use `canonicalize` because
it prefix the paths with `\\?\`,
read more here: https://stackoverflow.com/a/41233992/7387397
- Updated and enabled tests for windows, some are still failing
closes#8188
---------
Co-authored-by: Alexander Schlegel <alexander.schlegel@clicksports.de>
## [0.15.1] - 2024-12-13
### Features
- 38b1c2e editor: Create a command to apply all auto-fixes for the
current active text editor (#7672) (Nicholas Rayburn)
### Bug Fixes
- 2b187e5 linter: Fix configuration casing for
`typescript/no_this_alias` (#7836) (Boshen)
- 06e6d38 linter: Fix unicorn/prefer-query-selector to use the correct
replacement for getElementsByClassName (#7796) (Nicholas Rayburn)
- 7a83230 semantic: Missing reference when `export default` references a
type alias binding (#7813) (Dunqing)
Co-authored-by: Boshen <1430279+Boshen@users.noreply.github.com>
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.
