[danusha2345]

Fixes #2978.

What happened

c.ts imports foo through index.ts, which re-exports it from a.ts. When the barrel's clause is changed to b.ts and the tree is synced, bar keeps calling a.ts:foo; a fresh index gives b.ts:foo. The barrel declares nothing of foo, so the definition delta (CG-33) has nothing to rebind; no file was added for the walks below a barrel (#2665) or the added-files pass; the binding never failed, so the retries (#1240, #2744) never see it; and the name-matched-import pass (#2744's other half) reads only bindings a name match took. export * moves the same way, and a scoped sync of the barrel alone too.

The change

• The orchestrator reports modules whose re-exports changed. An import node is named by the module it names, so sync() samples a changed file's file\0module import pairs before the store replaces them, as it samples the definition pairs, and returns reExportsChangedFilePaths: the ES modules whose set of imported modules changed and that pass bindings on now (export … from) or lost an import. A body-only edit, or an import edit in a file that re-exports nothing, reports nothing.
• Their importers' bindings go back for the sweep (reopenReferencesThroughRetargetedModules in module-importers.ts): the edges each importer makes through the names it binds from the module, up through the modules that pass them on in turn (a second barrel over the first), with the failures parked under them, and the edges into the members of what the bindings pointed at, which a value typed by a binding reached by their own names (w.run() with w: Widget). It is the importer walk the removed-files pass uses, without the exclusion of edges into the file itself, and it runs after the name-matched-import pass (fix(sync): a name imported through a barrel links when an edit gives the barrel its re-export #2744), which reads the bindings a name match took before they go back. The sweep then binds them against the barrel as it is now.

Tests

__tests__/sync-barrel-retarget.test.ts (7 tests), each comparing the synced graph with a full index of the final tree:

• the issue's named re-export retargeted; an export * retargeted; a scoped sync of the barrel alone;
• a re-export taken away (the importer lands where a full index lands it);
• the change reaching the importer through a second barrel that passes the first one on;
• a value typed by the binding (new Widget(); w.run()) reaches the members of the new target;
• a body-only edit of the barrel reports nothing and re-resolves nothing.

6 of 7 fail on main (the control passes); all 7 pass here.

Full suite on main 01e0ac3 with the native kernel (CODEGRAPH_KERNEL_EXPECT=1): 9,278 passed, 55 skipped, 0 failed; tsc --noEmit clean.

🤖 Generated with Claude Code

[colbymchenry]

Thank you @danusha2345! Retargeting a barrel's re-export really did leave the files importing through it on the old module, and your importer walk fixed it. It landed in #3059 as your commit, with one change: the trigger now compares the barrel's export … from statements instead of the modules a file imports, so dropping a plain import from a widely imported module no longer re-opens every importer's bindings, and a name dropped from a clause is caught too. Thanks again!