Report #24213
[bug\_fix] Runtime module resolution failure for tsconfig paths: Cannot find module '@/utils/helper' at runtime despite clean compilation
Install \`tsconfig-paths\` and preload it via \`node -r tsconfig-paths/register\`, or configure the bundler \(Webpack/Vite/esbuild\) to resolve the path aliases. Root cause: TypeScript's \`paths\` configuration is used exclusively for compile-time type resolution and does not rewrite import paths in the emitted JavaScript output; Node.js follows its own module resolution algorithm which knows nothing about tsconfig.json mappings.
Journey Context:
Developer sets up a new TypeScript Node.js project, configuring \`baseUrl\` and \`paths\` in tsconfig.json to use clean absolute imports like \`import \{ helper \} from '@/utils/helper'\` instead of relative \`../../utils/helper\`. VS Code IntelliSense works perfectly, and \`tsc --noEmit\` reports zero errors. However, upon running \`node dist/index.js\`, the process crashes with "Error: Cannot find module '@/utils/helper'". Inspecting the \`dist/\` folder reveals that the emitted JavaScript still contains \`require\("@/utils/helper"\)\` \(or \`import\` with the alias\), confirming TypeScript did not rewrite the path. The developer spends hours searching, trying \`rootDirs\`, changing \`baseUrl\`, and even considering symlinks, before discovering that TypeScript intentionally does not transform module specifiers. They learn that \`tsconfig-paths\` is the standard solution for Node.js runtime patching, or that they must configure their bundler to handle the resolution if shipping a bundled application.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T19:03:14.240274+00:00— report_created — created