A TypeScript package ships `.d.ts` files and sets the `types` field in package.json, but after it adds an `exports` map, consumers on `"moduleResolution": "node16"` report that its types are gone. Why, and how do you fix it?

## The two eras of type resolution **Legacy (`"moduleResolution": "node"`).** The resolver reads `main` for JavaScript and the top-level `types` (or its old alias `typings`) for declarations. One entry point, two fields, no conditions. This is what almost every tutorial still shows. **Modern (`node16`, `nodenext`, `bundler`).** TypeScript follows the `exports` field the way Node does. `exports` is an **encapsulation boundary**: when it is present, only the paths it lists are reachable, and the legacy `main`/`types` fields are not consulted for those resolutions. Adding `exports` to a package that previously relied on `types` therefore removes the pointer to the declarations without touching a single `.d.ts`. ```json { "name": "@acme/client", "exports": { ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js", "require": "./dist/index.cjs" } } } ``` ## Why it sometimes still works, confusingly After resolving a subpath to a JavaScript file through `exports`, TypeScript will look for a declaration file **adjacent to it** with the matching name — `./dist/index.js` implies `./dist/index.d.ts`. Packages whose layout happens to satisfy that keep working without a `types` condition, which is exactly why the failure looks random from the outside: it depends on the package's output layout, not on anything the consumer did. Relying on it is fragile; declare the condition. ## Order matters, and it is a real bug source Condition objects are matched **top to bottom**, first match wins. `"default"` matches everything. So this map never delivers types: ```json { ".": { "default": "./dist/index.js", "types": "./dist/index.d.ts" } } ``` The rule is simple: `types` goes first in every condition object it appears in, and `default` goes last. The same applies inside nested condition objects — an `import` branch that itself has conditions needs `types` first within that branch too. ## Dual-format packages need more than one declaration Under `node16`, a file's module format is decided by its extension and the nearest `package.json` `"type"` — and that applies to **declaration files too**. A single `index.d.ts` in a `"type": "module"` package describes an ES module. Hand that to a consumer resolving through the `require` branch and the types describe the wrong module shape: the checker may reject `const x = require(...)` destructuring that works fine, or bless a default import that does not exist at runtime. The correct shape gives each format its own declaration: ```json { "exports": { ".": { "import": { "types": "./dist/index.d.mts", "default": "./dist/index.mjs" }, "require": { "types": "./dist/index.d.cts", "default": "./dist/index.cjs" } } } } ``` Those `.d.mts` and `.d.cts` files are not cosmetic renames — the extension is what tells the checker which module system the declaration describes. ## Subpaths and the deep-import trap Before `exports`, consumers could deep-import anything: `pkg/dist/internal/util`. Adding `exports` blocks every path you did not list, and the resulting error is about resolution, not about types, so it reads as a missing module. Every public subpath needs its own entry with its own `types` condition; a wildcard entry such as `"./features/*"` works but must still carry the condition. ## Diagnosing it 1. Reproduce as a **consumer**: pack the tarball, install it in a scratch project, and set the same `moduleResolution` your users have — this class of bug is invisible in the publishing repo. 2. Run the consumer's `tsc` with `--traceResolution` and read where the resolver went and what it rejected. 3. Check every branch of the map, not only the one your own tests exercise; `import` working while `require` is untyped is the most common half-broken state. ## Keep the legacy field anyway Dropping the top-level `types` field is a mistake even after adding conditions: consumers still on `"moduleResolution": "node"` read only that field. Keeping both costs two lines and covers both eras. The same reasoning applies to `main`.