**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`
This way we can get the class node faster. But I don't know if this is a
good way. In `eslint-plugin-react`, they get class node by scope. But
oxc cannot do the same way
@Boshen
The `ScopeTree.descendants` function would return all scopes starting
from the root, and wasn't truly descendants from a specific scope. To
improve this, I've renamed this function to `descendants_from_root` and
have introduced a new `descendants` function that does support from a
specific scope.
Furthermore, I've introduced helper functions to `SymbolTree` to make
reading symbols/scopes easier.
To verify this functionality, I enabled the `function_name` transformer
(and fixed it), and ran some example transforms. Here's the input:
```js
let fn;
fn = function (a, b, c) {
const d = "";
};
const func = function (arg) {
{
const value = "";
}
};
const f = function (f) {};
```
And the output using _the old implementation_. Note that all function
names are suffixed with a number, this is incorrect, since it was
inheriting far too many scopes.
```js
let fn;
fn = function fn1(a, b, c) {
const d = '';
};
const func = function func1(arg) {
{
const value = '';
}
};
const f = function f2(f) {
};
```
And here's the output with the new implementation. Note that only `f` is
suffixed with a number. That's because it has a shadowed argument of the
same name.
```js
let fn;
fn = function fn(a, b, c) {
const d = '';
};
const func = function func(arg) {
{
const value = '';
}
};
const f = function f1(f) {
};
```
Using the `realpath` for resolving browser field will lead to missing
queries.
This fixes a cases where `browserField` fails to read.
---
`styled-components` is using a trick for loading browser modules:
---
7c065e0b6f/packages/styled-components/package.json (L6C1-L12C5)
```json
"main": "dist/styled-components.cjs.js",
"module": "./dist/styled-components.esm.js",
"browser": {
"./dist/styled-components.esm.js": "./dist/styled-components.browser.esm.js",
"./dist/styled-components.cjs.js": "./dist/styled-components.browser.cjs.js"
},
```
Module resolution has to go from `"module":
"./dist/styled-components.esm.js"`, then to `browser`'s
`"./dist/styled-components.esm.js":
"./dist/styled-components.browser.esm.js"` part in order for things to
get resolved correctly.
---
Fixtures are hard to setup for this test case due to needing symlinks,
I've created https://github.com/oxc-project/oxc_resolver for tacking
such cases.
Creates a new nursery-level rule, `no-reduce-spread`, that prevents
spreading accumulator objects/arrays in `Array.prototype.reduce`.
The Tl;Dr of why this should be avoided is because it drastically
increases time/memory complexity in reductions. In general, it turns
potentially `O(1)`/`O(n)` memory operations into `O(n)`/`O(n^2)`, and
`O(n)` time into `O(n^2)`. For more details, refer to [this helpful blog
post](https://prateeksurana.me/blog/why-using-object-spread-with-reduce-bad-idea/).
Note that this rule doesn't exist in ESLint's default rule set or any
other ESLint plugin, although it looks like [there's been some interest
in it in the past](https://github.com/vercel/style-guide/issues/18).
Since there is no reference implementation to compare against, and thus
this could potentially have bugs, I've decided to make this a
nursery-level rule until we're sure it's stable and useful.
---
Edit:
- [ ] Sync with Biome -
https://biomejs.dev/linter/rules/no-accumulating-spread/
---------
Co-authored-by: Cameron Clark <cameron.clark@hey.com>
