fix: mark destructured const export bindings as exported (#2070) - #2294
fix: mark destructured const export bindings as exported (#2070)#2294carlos-alm merged 2 commits into
Conversation
Sorry, something went wrong.
collectExportedDeclarations (TS) / collect_exported_var_declarations (Rust)
skipped any declarator whose name field wasn't a plain identifier, so
`export const { a, b } = value` and `export const [a, b] = value` produced
Definition rows for a/b but no matching Export entries — the exported=1
UPDATE never fired even though the bindings are genuinely exported.
Both engines now walk the object_pattern/array_pattern name field the same
way the Definition-building side already does (via shared
collectObjectPatternNames/collectArrayPatternNames helpers extracted from
extractDestructuredBindings/extractArrayPatternBindings on the TS side, and
the existing collect_object_pattern_names/collect_array_pattern_names on the
Rust side), pushing one 'constant' Export per bound name. Restricted to
const, matching the Definition side's own let/var restriction.
docs check acknowledged: internal extractor bug fix, no README/CLAUDE.md/
ROADMAP surface (language list, feature list, architecture) changes needed.
Impact: 5 functions changed, 14 affected
Greptile SummaryThis PR aligns destructured const export collection with Definition extraction in both JavaScript engines.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains; the previously reported nested array-rest export omission is fixed in the current code. Important Files Changed
Reviews (2): Last reviewed commit: "fix: recurse into nested array-pattern r..." | Re-trigger Greptile |
Sorry, something went wrong.
| } | ||
| } | ||
| "array_pattern" if is_const => { | ||
| for name in collect_array_pattern_names(&name_n, source) { |
There was a problem hiding this comment.
Nested rest exports remain unmarked
When an exported const uses a nested array pattern as a rest target, such as export const [x, ...[a, b]] = value, collect_array_pattern_names omits a and b even though the Definition path creates both bindings, causing the Rust engine to leave these exports unmarked and diverge from the TypeScript engine.
Knowledge Base Used:
Sorry, something went wrong.
There was a problem hiding this comment.
Fixed in cf97b73 — collect_array_pattern_names's rest_pattern branch now recurses into a nested array_pattern the same way extract_array_pattern_bindings's Definition-side rest handling already did, instead of delegating to the plain-identifier-only extract_rest_identifier. Added regression tests on both engines (marks_exported_nested_array_pattern_rest_bindings_as_exports in Rust, "marks exported nested array-pattern rest bindings as exports" in TS) covering export const [x, ...[a, b]] = value.
Sorry, something went wrong.
Codegraph Impact Analysis5 functions changed → 14 callers affected across 1 files
|
Sorry, something went wrong.
#2070) Greptile review on PR #2294: collect_array_pattern_names's rest_pattern branch called the plain-identifier-only extract_rest_identifier, so a rest element nesting another array pattern (`...[a, b]`) got Definitions via extract_array_pattern_bindings's own recursive rest handling but no matching Export at all for `export const [x, ...[a, b]] = value` — diverging from both the Definition side and the TS engine, which already recursed here. Mirrors extract_array_pattern_bindings's rest_pattern handling directly in collect_array_pattern_names instead of delegating to extract_rest_identifier (left unchanged for its other two call sites — both object-pattern rest, which can only ever bind a plain identifier per the grammar). docs check acknowledged: internal extractor bug fix, no README/CLAUDE.md/ ROADMAP surface changes needed.
Sorry, something went wrong.
Summary
export const { a, b } = value and export const [a, b] = value never marked a/b as exported on either engine — collectExportedDeclarations (TS) and collect_exported_var_declarations (Rust) both skipped any declarator whose name field wasn't a plain identifier, so an object_pattern/array_pattern name field caused the declarator to be dropped entirely before pushing any Export. The matching Definition rows for a/b were created correctly by the sibling destructuring logic (extractDestructuredBindings/extract_destructured_bindings), so codegraph exports/dead-export analysis showed them as definitions but never as exports.
Both engines now walk the object_pattern/array_pattern name field the exact same way the Definition-building side already does, and push one 'constant' Export per bound name:
Restricted to const, matching the Definition side's own let/var restriction — export let { a } = ... still does not produce a Definition, so it must not produce an Export either.
Verification
Closes #2070