fix(extract): resolve alias re-exports and imports through barrels to the defining symbol (#1983)#2034
Open
HerenderKumar wants to merge 1 commit into
Open
Conversation
… the defining symbol (Graphify-Labs#1983)
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
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
Follow-up to #1983. e5a4b51 fixed the issue's direct reproducer, but its rewrite learns old→canonical symbol forms only from symbols a file defines. A barrel defines nothing — so a named re-export or import that resolves through a barrel still synthesizes an absolute-prefixed target no rewrite ever learns: the checkout path leaks into the edge target and the edge dangles.
Verified on current
v8head:for
export { formatDate } from '@/lib'/import { formatDate } from '@/lib'wheresrc/lib/index.tsis itself a barrel re-exporting from@/lib/utils.Fix
Three parts, extending existing machinery rather than adding a new pass:
_import_jsstampstarget_fileon symbol-levelre_exports/importsedges — the same transient hint the file-level edge has carried since Phantom self-cycles: same-basename cross-extension re-exports (X.ts → ./X.mjs) collapse to one node #1814 (no downstream reader; stripped at build).re_exportsedge to the defining symbol — iterating one hop per pass so multi-hop barrel chains resolve — and, when no chain leads to a real node, canonicalize the prefix anyway so a checkout-specific path never survives in an edge target.target_filefrom edge identity, so an alias edge (stamped) still matches the canonical twin the shared resolver emits (unstamped).Testing
re_exports/importstarget contains the checkout prefix (the issue's core "Expected" line).tests/test_js_import_resolution.pypasses 61/61 — including the e5a4b51 owned-symbol guard tests (test_alias_import_does_not_remap_an_owned_symbol_id,test_alias_import_preserves_owned_same_line_symbol_edge).tests/test_extract.py+tests/test_charmap_encoding.pyare name-for-name identical between this branch and cleanorigin/v8in my environment (31 pre-existing failures from missing grammar packs on both sides).Fixes #1983.