fix(linter/react): no only-export-components false positive on nested components - #24915
Open
veksa wants to merge 1 commit into
Open
fix(linter/react): no only-export-components false positive on nested components#24915veksa wants to merge 1 commit into
veksa wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Fixes a false positive in
react/only-export-componentswhere a non-exported, nested PascalCase function was flagged as a Fast Refresh violation.Closes #24854
The problem
Given code like this, oxlint incorrectly warned about
Inner:Inneris never exported, so it can't possibly affect Fast Refresh, and the upstreameslint-plugin-react-refreshcorrectly stays silent here. The pattern shows up in real code, for example factory helpers that build Recharts components.The cause
find_local_componentswas iterating over every node in the semantic tree, which meant it also picked up components declared deep inside other functions. The reference implementation only ever looks atprogram.body, so it never considers anything below the top level.The fix
I limited local component detection to top-level declarations by keeping only nodes whose parent is the
Program. Nested function expressions and declarations live under aReturnStatement,BlockStatement, etc., so they're no longer collected.Once that filter is in place the old
is_exportedhelper becomes redundant: a node whose parent is theProgramcan't sit under anexportdeclaration, since inline exports always wrap their declaration in anExportNamedDeclarationorExportDefaultDeclaration. So I dropped that helper and its now-unusedNodeIdimport.I also added a couple of pass tests covering the reproduction from the issue, both with a nested named function expression and a nested arrow function.
AI disclosure
This change was written with the help of an AI assistant, and I've reviewed and tested it myself before submitting.