Cannot find module or its type declarations after switching to "moduleResolution": "bundler"

Typescript·Sep 13, 2026·intermediate·
Quick answer

`"moduleResolution": "bundler"` (recommended for projects using Vite, esbuild, or similar) resolves modules the way real bundlers do, which is stricter about a package's `exports` field than the older `node` resolution mode was. A package resolving fine under `node` mode can fail under `bundler` mode if its `exports` map doesn't declare a `types` condition, or omits a subpath you're importing.

What causes this error

"moduleResolution": "bundler" mirrors how modern bundlers actually resolve packages, respecting the exports field strictly — including requiring a `"types"` condition inside `exports` for the compiler to find type declarations at all. Some packages, especially older ones, declare `exports` for runtime resolution but forget the `types` condition, which worked fine under the older `"node"` resolution mode but breaks here.

The Fix

// tsconfig.json
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "module": "esnext"
  }
}

// If a specific package fails to resolve its types under this mode:
// 1. Check if a newer version of the package fixed its exports map
// 2. As a stopgap, add an explicit path mapping to its .d.ts file
{
  "compilerOptions": {
    "paths": {
      "problem-package": ["./node_modules/problem-package/dist/index.d.ts"]
    }
  }
}

Common causes / variations

  • A dependency's `exports` field missing the `"types"` condition, or ordering it after `"import"`/`"require"` (order matters — `types` must come first)
  • Deep subpath imports into a package that its `exports` map doesn't expose
  • Migrating from CRA/older tooling straight to `bundler` resolution without auditing dependencies for exports-map completeness

Related errors

See also: ERR_PACKAGE_PATH_NOT_EXPORTED (Node.js), baseUrl deprecated.

Was this fix helpful?

Comments

Loading comments...