fix: mark destructured const export bindings as exported (#2070) - #2294
Conversation
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
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 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| } | ||
| } | ||
| "array_pattern" if is_const => { | ||
| for name in collect_array_pattern_names(&name_n, source) { |
There was a problem hiding this comment.
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:
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.
Codegraph Impact Analysis5 functions changed → 14 callers affected across 1 files
|
#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.
1 participant
Summary
export const { a, b } = valueandexport const [a, b] = valuenever markeda/bas exported on either engine —collectExportedDeclarations(TS) andcollect_exported_var_declarations(Rust) both skipped any declarator whose name field wasn't a plainidentifier, so anobject_pattern/array_patternname field caused the declarator to be dropped entirely before pushing anyExport. The matchingDefinitionrows fora/bwere created correctly by the sibling destructuring logic (extractDestructuredBindings/extract_destructured_bindings), socodegraph exports/dead-export analysis showed them as definitions but never as exports.Both engines now walk the
object_pattern/array_patternname field the exact same way the Definition-building side already does, and push one'constant'Exportper bound name:collectObjectPatternNames/collectArrayPatternNamesname-only helpers out ofextractDestructuredBindings/extractArrayPatternBindings(used by both, so they can never drift), and call them fromcollectExportedDeclarations.collect_object_pattern_names/collect_array_pattern_nameshelpers (already shared elsewhere) fromcollect_exported_var_declarations.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
npm run lint)npm test— 275 files / 4470 tests;cargo test -p codegraph-core --lib— 780 tests)codegraph diff-impact --staged -Tconfirms the change is contained to the destructuring/export helper family (5 functions, 14 callers, 1 file)Closes #2070