fix(resolve): treat bare . / .. as relative directory imports (#5141)#5151
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough
ChangesRelative specifier resolver fix
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
) @tanstack/table-core failed to link (Undefined symbols: __getVisibleLeafColumns). Its source uses 'import { _getVisibleLeafColumns } from ".."' (package barrel), where '..' resolves to the package index.ts (export * from features/...). The import resolver detected relative imports via starts_with("./")||"../"; bare '.' and '..' (directory imports resolving to index) matched neither, so 'from ".."' fell through to bare-package resolution, import.resolved_path never matched the index module, and every name imported through it lowered to an unresolved raw extern symbol -> link failure. 'from "../index"' worked. Fix: shared is_relative_specifier() that also matches exact '.' / '..', used by resolve_relative_import_path, resolve_import, and the declaration-sidecar resolver. tanstack table-core now links and runs (getRowModel().rows.length=3, matches Node). No regression on ./ or ../foo imports.
cff3e30 to
90ab37e
Compare
Fixes #5141 (
compilePackages: @tanstack/table-corelink failure).Symptom
Root cause
@tanstack/table-core's source uses the package-barrel idiom —features/ColumnSizing.tsdoes:and
index.tsdoesexport * from './features/ColumnVisibility'.The import resolver (
crates/perry/src/commands/compile/resolve.rs) detected relative imports withstarts_with("./") || starts_with("../"). The bare specifiers"."and".."(current/parent directory imports — valid ECMAScript, resolving to that directory'sindex) match neither, soimport { X } from '..'fell through to bare-package resolution.import.resolved_pathwas then never matched to the index module innative_modules, so every name imported through it lowered to an unresolved raw extern symbol (_getVisibleLeafColumns, notperry_fn_...) → link failure.from '../index'worked only because it carries the"../"prefix. The leading underscore was a red herring — a directly-definedindexexport imported viafrom '..'failed identically.Fix
A shared
is_relative_specifier()helper that also matches exact"."/"..", used byresolve_relative_import_path,resolve_import, and the declaration-sidecar resolver.Validation
import { x } from '..'through anexport *barrel) — was link-fail, now runs.createTable({...}).getRowModel().rows.length→3,getAllLeafColumns().length→1, matching Node byte-for-byte../and../fooimports (uuid, dayjs, re-export repros) still resolve;-p perryresolve tests pass.This is general — any
import … from '.'/'..'(directory→index) was affected.Summary by CodeRabbit
.and..) consistently with explicit relative paths (./and../).