Fix SCREAMING_SNAKE_CASE constant exported via export { Name } incorrectly treated as React component - #114
Open
rakleed wants to merge 2 commits into
Conversation
…ectly treated as React component
rakleed
changed the title
export { Name } incorrectly treated as React component
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
1 participant
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.
Fixes #113
Follow-up to #110, same code path:
export { Name }specifiers referring to a localconst/letvariable were only checked by name (reactComponentNameRE), never by their actual initializer, unlike inlineexport const X = .... Since the name regex allows underscores, SCREAMING_SNAKE_CASE constants (ENTITY_TYPE,COLUMN_TEMPLATE, ...) were misidentified as components when re-exported via a specifier list, causing false positives whenever the same file also exports something correctly classified as non-component (e.g. a plain class, per #110).This mirrors the
ClassNamescope-resolution added in #110: for a specifier referring to a local variable declarator, resolve its initializer from scope and run it through the normalhandleExportIdentifier(identifier, init)path instead of the name-only fallback.Added regression tests for both the false positive (valid case) and to confirm real component/non-component mixes via
export { }are still caught (invalid case).