Report #6112
[bug\_fix] Runtime module resolution failure for tsconfig paths: 'Error: Cannot find module '@src/utils' in Node.js despite successful tsc compilation and IDE autocomplete
TypeScript's 'paths' mapping is compile-time only for type resolution and does not rewrite import paths in emitted JavaScript. Node.js's native module loader does not understand these mappings. The fix is to either: \(1\) Use a runtime loader that supports path remapping \(e.g., 'tsx', 'ts-node' with 'tsconfig-paths/register'\), \(2\) Post-process emitted JS with 'tsc-alias' to rewrite paths, or \(3\) Migrate to Node.js native subpath imports using the 'imports' field in package.json which is supported natively by Node.js >=12 without build-step rewriting.
Journey Context:
The developer configures a monorepo with 'tsconfig.json' containing '"paths": \{ "@src/\*": \["./src/\*"\] \}' to avoid relative path hell. VS Code IntelliSense works perfectly, navigating to the correct files. 'tsc --noEmit' reports no errors. However, running 'node dist/index.js' immediately throws 'Error: Cannot find module '@src/utils''. The developer checks 'dist/index.js' and sees 'import \{ utils \} from '@src/utils';' preserved verbatim. They try adjusting 'baseUrl', clearing caches, and reinstalling node\_modules. The 'aha' moment comes when realizing TypeScript intentionally 'leaves the module specifier alone' as it is a type-checker, not a bundler. The emitted code must be runnable by Node.js, which knows nothing about tsconfig paths. The solution requires either a runtime loader like 'tsx' that reads tsconfig paths, or a post-build tool to rewrite the paths to relative './' paths.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T23:12:11.794011+00:00— report_created — created