-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
feat!: enable JSX reference tracking #20152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for docs-eslint canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 LGTM, thanks! I couldn't find any other uses that need to be updated. But I'm not a deep expert here and should defer to a second review.
|
Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update. |
aladdin-add
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
|
I think we should update docs here, as eslint/docs/src/extend/scope-manager-interface.md Lines 274 to 277 in a463e7b
And types: Lines 179 to 180 in a463e7b
|
|
I think we could also update the eslint/lib/rules/no-useless-assignment.js Lines 338 to 348 in 3383e7e
eslint/lib/rules/no-useless-assignment.js Line 532 in 3383e7e
|
d441611
|
I’ve updated the scope manager documentation, the interface JSXIdentifier extends ESTree.BaseNode {
type: "JSXIdentifier";
name: string;
}or use an existing type package such as |
I think an inline definition would be fine, but would like @fasttime's opinion as this should probably be aligned with eslint/js#709 (and we'll eventually just re-export types from |
I also think an inline definition should be fine. ESLint doesn’t import types from |
|
I’ve updated the type accordingly. This should now be ready for review. |
|
Changes overall LGTM, thanks. |
mdjermanovic
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks! Leaving open for @nzakas to verify.
snitin315
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks! Left an optional suggestion.
| } | ||
| ``` | ||
|
|
||
| Prior to v10.0.0, ESLint did not recognize that `<Card>` is a reference to the imported `Card`, which could result in false positives such as reporting `Card` as "defined but never used" ([`no-unused-vars`](../rules/no-unused-vars)) or false negatives such as failing to report `Card` as undefined ([`no-undef`](../rules/no-undef)) if the import is removed. Starting with v10.0.0, `<Card>` is treated as a normal reference to the variable in scope. This brings JSX handling in line with developer expectations and improves the linting experience for modern JavaScript applications using JSX. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Prior to v10.0.0, ESLint did not recognize that `<Card>` is a reference to the imported `Card`, which could result in false positives such as reporting `Card` as "defined but never used" ([`no-unused-vars`](../rules/no-unused-vars)) or false negatives such as failing to report `Card` as undefined ([`no-undef`](../rules/no-undef)) if the import is removed. Starting with v10.0.0, `<Card>` is treated as a normal reference to the variable in scope. This brings JSX handling in line with developer expectations and improves the linting experience for modern JavaScript applications using JSX. | |
| Prior to v10.0.0, ESLint did not recognize that `<Card>` is a reference to the imported `Card`, which could result in false positives such as reporting `Card` as "defined but never used" ([`no-unused-vars`](../rules/no-unused-vars)) or false negatives such as failing to report `Card` as undefined ([`no-undef`](../rules/no-undef)) if the import is removed. Starting with v10.0.0, `<Card>` is treated as a normal reference to the variable in scope. This brings JSX handling in line with developer expectations and enhances the linting experience for modern JavaScript applications that use JSX. |
nzakas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:
This PR enables JSX reference tracking in ESLint by passing the
jsxoption toeslint-scope. This feature was already implemented ineslint-scopebut wasn't being utilized in ESLint.What changes did you make? (Give an overview)
lib/languages/js/index.jsandlib/linter/linter.jsto passjsx: ecmaFeatures.jsxto the scope analyzerno-undefrule to verify JSX element references are properly trackedno-use-before-definerule to verify JSX usage follows definition order rulesFixes #19495
Is there anything you'd like reviewers to focus on?