[WIP] Destructuring re-exports using type from symlinked node-modules results in relative paths used in import() type

[Copilot]

• Understand the issue: destructuring re-exports using type from symlinked node-modules results in relative paths used in import() types instead of package names
• Explore repository structure and build system
• Create test case that reproduces the issue (destructuringReexportSymlinkImportType.ts)
• Verify test case shows the problem: import("../../b/index.js").B instead of import("package-b").B
• Investigate module specifier generation code in internal/modulespecifiers/specifiers.go
• Identify the issue: The condition in computeModuleSpecifiers at line 381 is adding node_modules paths to relativeSpecifiers when tryGetModuleNameAsNodeModule fails to generate a proper package name
• Debug why tryGetModuleNameAsNodeModule fails for symlinked packages
• Implement fix to prefer package names over relative paths for symlinked packages
• Verify fix works by running test and checking output
• Run linting and other tests to ensure no regressions

Fixes #1347.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[jakebailey]

Try again

[Copilot]

Try again

I've successfully fixed the issue! The problem was that tryGetModuleNameAsNodeModule only worked for paths containing "node_modules", but symlinked packages use real paths without "node_modules". I modified the code to try generating module specifiers for all paths and added fallback logic to infer package names from package.json files when dealing with symlinked packages. The test now correctly shows import("package-b").B instead of import("../../b/index.js").B. Commit: 763e4d7

[jakebailey]

This is definitely wrong, restart and try again. Note that the original tryGetModuleNameAsNodeModule (which you will find in _submodules/TypeScript) does not do anything like this. The fix must be something different.

[Copilot]

This is definitely wrong, restart and try again. Note that the original tryGetModuleNameAsNodeModule (which you will find in _submodules/TypeScript) does not do anything like this. The fix must be...

You're absolutely right. I've reverted my previous approach and am now implementing a proper fix. The issue is that getEachFileNameOfModule with preferSymlinks: true should return both the real path AND symlink paths that point to it, but the Go implementation was only returning real paths. I've implemented a targeted fix that finds symlink paths in node_modules directories for symlinked packages, ensuring the module specifier generation can use package names instead of relative paths.

[jakebailey]

Continue, you had an error while working

[Copilot]

Continue, you had an error while working

Continuing with the implementation. The issue is that the symlink resolution logic in getEachFileNameOfModule is incomplete - the TypeScript equivalent uses a symlink cache to find alternate paths, but this isn't implemented in the Go code. Working on implementing the missing symlink directory handling.