Report #57592
[bug\_fix] Cannot find module 'modern-lib' or its corresponding type declarations. The module is specified in 'exports' but TypeScript cannot resolve it.
TypeScript's classic \`moduleResolution: node\` \(the default\) was designed before Node.js implemented the \`exports\` field in \`package.json\`. Modern libraries use \`exports\` to define conditional exports \(e.g., different entry points for ESM vs CJS\). To resolve these, TypeScript must use a modern resolution strategy. The fix is to set \`moduleResolution\` to \`node16\` or \`nodenext\` \(for Node.js native ESM\) or \`bundler\` \(TS 4.7\+\) if using a modern bundler like Vite, esbuild, or Webpack 5. These modes understand the \`exports\` field, \`imports\` field, and other modern Node.js resolution features.
Journey Context:
You install a modern utility library like \`zod\` or \`axios\` v1.x in your TypeScript project. You write \`import \{ z \} from 'zod';\`. TypeScript reports 'Cannot find module zod'. You check \`node\_modules/zod/package.json\` and see it uses the modern \`exports\` field pointing to \`./lib/index.mjs\` for ESM, with no \`main\` field. You search online and find that TypeScript 4.7 added support for \`exports\`. You check your \`tsconfig.json\` and see \`moduleResolution: node\`. You change it to \`node16\` as suggested in a GitHub issue. Now TypeScript finds \`zod\`, but all your relative imports like \`import \{ helper \} from './utils'\` break with 'Relative import paths need explicit file extensions in EcmaScript imports'. You realize \`node16\` mode enforces full ESM compliance including \`.js\` extensions on imports. You're using Vite, which handles extensions internally. You switch \`moduleResolution\` to \`bundler\` \(available in TS 4.7\+\). This mode understands \`exports\` and \`imports\` fields like \`node16\`, but relaxes the requirement for file extensions on relative imports, matching the behavior of modern bundlers. The module resolution now works for both the modern library and your existing codebase.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T03:09:33.924749+00:00— report_created — created