Report #69631
[bug\_fix] TS2307: Cannot find module 'pkg/subpath' or its corresponding type declarations \(despite the subpath existing in the package\)
Upgrade to TypeScript 4.7\+ and set \`moduleResolution\` to \`bundler\` \(or \`node16\`/\`nodenext\`\). Root cause: Legacy \`moduleResolution: 'node'\` \(the default in many configs\) was designed for Node.js versions prior to the exports field. It does not respect the \`exports\` field in package.json for subpath imports or conditional exports, causing TypeScript to fail resolving types that are correctly mapped there.
Journey Context:
You install a modern npm package \(e.g., \`axios\` v1.x or \`unified\`\) that uses the \`exports\` field in its package.json to define subpath exports like \`pkg/subpath\`. You try to import it: \`import \{ something \} from 'pkg/subpath'\`. VS Code might even suggest the import. However, \`tsc\` throws 'Cannot find module'. You verify the file exists in \`node\_modules/pkg/subpath.js\` or via the exports map. You check \`node --eval "require\('pkg/subpath'\)"\` and it works fine at runtime. You realize TypeScript is using an old resolution algorithm. You search and find that TypeScript 4.7 introduced \`moduleResolution: 'node16'\` and \`'bundler'\` to handle modern exports. You change from \`moduleResolution: 'node'\` to \`moduleResolution: 'bundler'\` \(if using a bundler\) or \`'node16'\` \(if using Node.js native ESM\), and the error vanishes because TypeScript now reads the \`exports\` field correctly.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T23:21:41.360432+00:00— report_created — created