A dependency imports fine at runtime, but `tsc` reports TS2307 "Cannot find module 'pkg/utils' or its corresponding type declarations" — the package exposes that subpath only through an `exports` map in its package.json, and the tsconfig sets `"moduleResolution": "node10"`. What is going on, and what do `node16`/`nodenext` and `bundler` change?

## The two eras of resolution The original algorithm was structural: to resolve `pkg/utils`, look for `node_modules/pkg/utils.js`, then `node_modules/pkg/utils/index.js`, and so on up the directory tree. Any file inside a package was reachable by its path. `moduleResolution: "node10"` — the mode that used to be spelled `"node"` — is TypeScript's model of that era, with declaration files substituted for JavaScript ones (`utils.d.ts`, `index.d.ts`, the `types` field of package.json). The modern era added `exports` to package.json: an explicit map from public subpaths to files, which also *encapsulates* the package — anything not listed becomes unreachable, even if the file is right there on disk. `node10` does not read that map. So it fails in two opposite directions: it cannot find subpaths that exist only as `exports` entries, and it happily resolves internal files the package never meant to expose. ## What each mode does **`node10`** — legacy directory walk. Honours `main` and `types`/`typings`, index-file fallback, `@types` lookup. Ignores `exports` and `imports`. Its only remaining justification is a project that genuinely still resolves under those rules, or an old codebase not yet migrated. **`node16` / `nodenext`** — the modern algorithm. These read `exports` and `imports`, and crucially they make resolution *depend on the importing file's module format*. A file is ESM or CommonJS according to the nearest package.json `type` field and the `.mts`/`.cts` extensions; from an ESM file the `import` condition matches, from a CommonJS file the `require` condition does. They also enforce the ESM rule that relative specifiers carry explicit file extensions. `nodenext` tracks the latest behaviour as it evolves; `node16` pins to the semantics of that release line. **`bundler`** — reads `exports` like the modern modes, but drops the parts that are specific to a runtime's own loader: no mandatory file extensions on relative imports, and conditions resolved the way a bundler resolves them rather than by the importing file's format. Because it assumes a bundler will do the real resolution, TypeScript only allows it with `module` set to `preserve` or an ES-module setting; combining it with `module: commonjs` is rejected outright. ## The `types` condition Within an `exports` map, TypeScript looks for a `types` condition to find declarations: ```json { "exports": { "./utils": { "types": "./dist/utils.d.ts", "import": "./dist/utils.mjs", "require": "./dist/utils.cjs" } } } ``` Conditions are matched **in order**, so `types` must be listed before `import`, `require` and `default` — a map that puts it last will never match it, and the package looks untyped to the modes that read `exports` at all. Under `node10` none of this is visible; the historical workaround packages used for that mode is the `typesVersions` field, which maps subpaths to declaration files in a way the old algorithm can follow. ## Diagnosing the reported failure The telltale is precisely the asymmetry in the question: the runtime is satisfied and the checker is not. That combination points at a resolution-mode mismatch, not at a missing dependency. The checks worth running, in order: does the package.json have an `exports` map; is the subpath listed there; is there a `types` condition and is it first; and what `moduleResolution` is actually in effect (it has a default derived from `module`, so a project that never set it explicitly may be on `node10` without anyone deciding that). The fix is to move to a mode that matches reality. If the emitted files are executed by a runtime implementing the modern algorithm, that is `node16` or `nodenext` — which also brings the extension requirement and the format-sensitive conditions, so expect a batch of new errors on relative imports the first time. If a bundler resolves them, `bundler` is the honest description of what happens and avoids imposing the extension rule on code no runtime loads directly. ## Why this matters beyond the error message Resolution mode determines *which declaration file* the checker reads, and a dual-published package can legitimately ship different declarations for its ESM and CommonJS entry points. Under `node10` you get whatever `types` points at, regardless of how the module is actually loaded — so the checker may be describing the build you are not running. That is the deeper reason to move off it: not the error, but the silent possibility of checking against the wrong file.