After adding `"types": ["node"]` to compilerOptions in a tsconfig.json, every test file starts failing with "Cannot find name 'describe'". What does the `types` option control, and how does it differ from `typeRoots`?

## The implicit global inclusion nobody configures Most TypeScript projects never think about how names like `describe` or `it` become available without an import. The mechanism is automatic type inclusion: the compiler enumerates the folders in `typeRoots` — by default `node_modules/@types` in the containing directory and every parent directory, up to the filesystem root — and includes *every* package it finds there in the compilation. Those packages typically contain global declarations, so their symbols are visible in every file. This default is convenient and slightly out of control: installing any dependency that happens to pull in an `@types` package silently adds globals to your program. ## What `types` does `types` turns that default into an explicit allow-list: ```json { "compilerOptions": { "types": ["node", "vitest/globals"] } } ``` The key point — and the source of the reported failure — is that it is a **replacement**, not an addition. The moment you write `"types": ["node"]`, the automatic inclusion of everything else stops. The declaration package that provided `describe` and `it` is no longer part of the compilation, and the names become unresolved identifiers. Nothing was uninstalled; it simply stopped being included. `"types": []` is the extreme form: no automatic global inclusion at all. That is a deliberate and often good setting for a library, because it guarantees that no ambient globals leak in from a transitive dependency — for instance, browser-targeted code that accidentally compiles against server-side globals and then fails in a browser. Entries may also name subpaths, as in `"vitest/globals"`, when a package publishes its global declarations under a subpath rather than as a top-level `@types` package. ## What `typeRoots` does `typeRoots` controls *where* that automatic inclusion looks. Setting it to `["./typings", "./node_modules/@types"]` says: scan those two folders instead of the default upward walk. It is the option you reach for when hand-written declaration packages live in a project folder rather than in `node_modules`, or when you want to stop the compiler climbing out of a monorepo package into a parent's `@types`. The division of labour is clean: `typeRoots` = which folders are scanned, `types` = which of the packages found there are actually included. Restricting `typeRoots` and restricting `types` both narrow the global surface, but through different levers, and confusing them is the classic tell in an interview answer. ## What neither option touches Both apply only to *implicit* inclusion. If a file writes `import { readFile } from 'node:fs'`, the declarations for that module are resolved through ordinary module resolution and are unaffected by whether `node` appears in `types`. The distinction matters: `types` governs ambient globals, not the ability to import a typed package. That is why removing an entry can break a file that never imported anything and leave an importing file untouched. Neither option has any effect on emit. Declaration packages are erased like all types; changing these lists changes what the checker sees, never what runs. ## Fixing the reported failure Three reasonable responses, in rough order of preference: 1. **Add the entry.** If tests and application code share one compilation, list the test framework's globals alongside `node`. 2. **Separate the compilations.** Give the tests their own tsconfig that extends the base one and adds the test types, so application code cannot accidentally reference a test global. This is the answer that shows design sense — test globals leaking into production code is a real defect class. 3. **Import instead of relying on globals.** Most test frameworks also expose their API as named imports, which removes the dependency on ambient globals entirely and sidesteps the option. What is *not* a fix is deleting the `types` entry and going back to the default, if you added it for a reason — the reason was almost certainly to stop unrelated globals leaking in, and that reason still holds.