feat(linter): react/exhaustive-deps#7151
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
95fa95d to
e4715ae
Compare
a9758db to
1cd2f0b
Compare
99854fb to
97c5918
Compare
|
Rough first draft but most of the way their. would appreciate some early reviews as this was a massive amount of work and i don't want to go too far 🙂 |
This is amazing! I would run it through oxlint ecosystem ci and see what happens. |
camchenry
left a comment
There was a problem hiding this comment.
This looks pretty good overall, I didn't thoroughly review all of the code (there is a lot!) but I took a look at the diagnostics and have a few help text suggestions. I think keeping this in nursery and continuing to iterate on it would be good
|
Note: once merged, manually add this rule to oxlint-ecosystem-ci's CI script. We then change this to correctness after running it for 2 - 4 weeks. |
camchenry
left a comment
There was a problem hiding this comment.
it's hard to review all of this code, but I have skimmed over most of it and not too much stuck out to me. I think this is ready to start being tested in nursery
d66e466 to
8f927a2
Compare
|
@Boshen did it look ok in the ecosystem ci? https://github.com/oxc-project/oxlint-ecosystem-ci/actions/runs/11755920122/job/32751524336 thanks for testing for me 🙂 |
CodSpeed Performance ReportMerging #7151 will not alter performanceComparing Summary
|
Merge activity
|
|
Hit the merge button too quickly 😅 In Some false positives: It's picking up type annotation |
|
Do you also need to include function calls? |
The span is not pointing at the member expression. |
|
This looks pretty weird |
|
kibana has the most violations, you may want to test it during developement. |
looks like they've got it disabled? for this file https://github.com/elastic/kibana//blob/2466a172af66452bdd939dddc56506faba7ffb7a/.eslintrc.js#L1623 when i run eslint on this file, it reports (same as us) |
Interesting case, how should this be handled? |
Boshen
left a comment
There was a problem hiding this comment.
Feel free to merge after a final self review.
|
@Boshen i guess we should be reporting the same (or at least very similar spans to react? if ok with you, i'll make an issue to track bits that aren't exactly complete for this rule |
Indeed, current span breaks already written eslint ignores. |
a4f7675 to
171e62c
Compare
171e62c to
3dcac1a
Compare
## [0.12.0] - 2024-11-20 - 20d9080 linter: [**BREAKING**] Override plugins array when passed in config file (#7303) (camchenry) ### Features - 1d9f528 linter: Implement `unicorn/prefer-string-raw` lint rule (#7335) (Ryan Walker) - d445e0f linter: Implement `unicorn/consistent-existence-index-check` (#7262) (Ryan Walker) - 01ddf37 linter: Add `allowReject` option to `no-useless-promise-resolve-reject` (#7274) (no-yan) - 755a31b linter: Support bind function case for compatibility with `promise/no-return-wrap` (#7232) (no-yan) - 428770e linter: Add `import/no-namespace` rule (#7229) (Dmitry Zakharov) - 9c91151 linter: Implement typescript/no-empty-object-type (#6977) (Orenbek) - 2268a0e linter: Support `overrides` config field (#6974) (DonIsaac) - 3dcac1a linter: React/exhaustive-deps (#7151) (camc314) - d3a0119 oxlint: Add `cwd` property to `LintRunner` (#7352) (Alexander S.) ### Bug Fixes - ba0b2ff editor: Reload workspace configuration after change (#7302) (Alexander S.) - bc0e72c linter: Handle user variables correctly for import/no_commonjs (#7316) (Dmitry Zakharov) - bf839c1 linter: False positive in `jest/expect-expect` (#7341) (dalaoshu) - ff2a1d4 linter: Move `exhaustive-deps` to `react` (#7251) (camc314) - df5c535 linter: Revert unmatched rule error (#7257) (Cameron A McHenry) - c4ed230 linter: Fix false positive in eslint/no-cond-assign (#7241) (camc314) - ef847da linter: False positive in `jsx-a11y/iframe-has-title` (#7253) (dalaoshu) - 62b6327 linter: React/exhaustive-deps update span for unknown deps diagnostic (#7249) (camc314) ### Documentation - 4c124a8 editor/vscode: Update VS Code readme with installation instructions and available features (#7306) (Nicholas Rayburn) ### Refactor - c6a4868 linter: Temporarily remove unknown rules checking (#7260) (camchenry) ### Testing - 5190b7f editor: Add test setup (#7361) (Alexander S.) Co-authored-by: Boshen <1430279+Boshen@users.noreply.github.com>
…dentifier it is a dependency of hook (#18350) From what I understand from the logic, only variables declared at the component level should be dependencies; otherwise, they are normal variables outside of the component or inside the child scope. import { useEffect } from "react"; 1. Variable was declared outside the component scope ```tsx const id = crypto.randomUUID(); function MyComponent() { useEffect(() => { console.log(id); }, []); return <div />; } ``` 2. Variable was declared inside a child scope ```tsx function MyComponent() { useEffect(() => { const id = crypto.randomUUID(); console.log(id); }, []); return <div />; } ``` 3. Variable was redeclared in the same scope (should add `id` to dependencies) ```tsx function MyComponent() { const id = crypto.randomUUID(); useEffect(() => { const id = crypto.randomUUID(); console.log(id); }, []); return <div />; } ``` Only case 3) should add `id` into the dependencies. So simplifying the logic to check `declaration.scope_id() != component_scope_id` is sufficient. ### Performance This should have a significant performance improvement as it avoids the unnecessary two loops. By checking the initial PR of this rule #7151, there are also no performance changes, so I guess there are no such cases in the benchmark files.


Firstly, a massive thanks to @alisnic for starting this (incredibly complicated) lint rule in #2637 !
closes #2637
relates to #2174