This PR adds benchmarks for the lexer. I'm doing some work on optimizing
the lexer and I thought it'd be useful to see the effects of changes in
isolation, separate from the parser.
These benchmarks may not be ideal to keep long-term, but for now it'd be
useful.
In order to do so, it's necessary for `oxc_parser` crate to expose the
lexer, but have done that without adding it to the docs, and using an
alias `__lexer`.
When we developed linter for #1141 , we needed to configure some
settings for `jsx-a11y`, which was not supported before, but I am trying
to support it now.
like this:
```
fn config() -> serde_json::Value {
serde_json::json!([2,{
"ignoreNonDOM": true
}])
}
fn settings() -> serde_json::Value {
serde_json::json!({
"jsx-a11y": {
"components": {
"Button": "button",
}
}
})
}
let pass = vec![
("<Button />", Some(config()), Some(settings())),
];
```
**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`
closes#273closes#814
HIR is removed from this PR, with the minifier being commented out.
HIR is a wonderful idea for compiling to lower languages, but after
sitting on it for a few months I found that it only adds confusion and
uncertainties to both myself and future contributors.
It also adds too much burden to maintainers if we plan to support more
downstream tools.
1 AST is the only way.
