fix(extractors): export line matches the declaration, not the export keyword - #2460
Merged
carlos-alm merged 1 commit intoAug 11, 2026
Merged
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
…keyword collectExportedDeclarations/collect_exported_var_declarations computed a single export line from the wrapping export_statement node and applied it to every branch, while the matching Definition row for that declaration is built from the declaration's own node (or, for a function-valued declarator, the function value's own node, per #2265). Whenever export and its declaration start on different lines -- valid JS, since ASI doesn't apply between export and its declaration -- the two rows diverged and the exported=1 UPDATE (matched by name/kind/file/line, #1728) silently never fired. Each branch now sources its line from the same node its own Definition already uses, mirrored across both engines. Closes #2293 Impact: 3 functions changed, 0 affected
Copy link
Copy Markdown
Contributor
Greptile SummaryThe PR aligns JavaScript export metadata lines with the AST nodes used to create matching definitions.
Confidence Score: 5/5The PR appears safe to merge, with the changed export-line calculations matching their corresponding definition-line calculations across both engines. The TypeScript and Rust implementations consistently select declaration nodes for named and constant definitions and function-value nodes for function-valued definitions, while the added tests cover the affected multiline cases. Important Files Changed
Reviews (1): Last reviewed commit: "fix(extractors): export line matches the..." | Re-trigger Greptile |
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
Codegraph Impact Analysis3 functions changed → 7 callers affected across 1 files
|
Sorry, something went wrong.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Summary
Note on scope
While writing regression tests, found that a bare export\n<declaration> (the issue's own illustrative repro) doesn't actually reach this code at all — tree-sitter-javascript fails to parse a newline-separated bare export followed by a declaration keyword as a single export_statement, silently dropping the export relationship entirely (worse than a line mismatch). That's an upstream grammar limitation, filed separately as #2459 — not addressed here. This PR's tests use export default/multi-binding export const reproductions, which the grammar does parse correctly across multiple lines, to exercise the actual line-computation fix.
Closes #2293
Test plan