A TypeScript 6 upgrade can produce a wall of errors for process, Buffer, test globals, or built-in Node modules even though @types/node is installed. The package exists, but TypeScript no longer includes ambient type packages automatically.
The useful question is not whether the release sounds modern. It is whether the changed default or capability affects the way your project installs, compiles, resolves modules, or runs in production.
Quick answer
Declare the ambient environments the project uses with an explicit types array. For a Node service, start with types: ["node"]; add test-runner types only in the configuration that checks tests.
{
"compilerOptions": {
"types": ["node"]
}
}what changed
The types option now defaults to an empty array. TypeScript recommends explicit entries for more predictable builds and better performance; types: ["*"] restores broad older behavior but is less controlled.
This is a version-specific change. Pin the tool or runtime while migrating so a teammate and CI do not test a different contract by accident.
where teams will notice it
Different packages can declare the same global names. Explicit ambient types prevent a frontend build from accidentally inheriting Node or test-runner globals it cannot use at runtime.
A small smoke test is more useful than assuming the changelog covers your architecture. Reproduce the workflow from a clean checkout with the same command production uses.
a safe migration
- List the actual runtimes checked by each tsconfig.
- Add only their ambient type packages.
- Use a separate test tsconfig when needed.
- Run the compiler from CI, not just the editor.
Change one resolution or security boundary at a time. That keeps failures attributable and makes rollback straightforward.
the mistake to avoid
Do not add every installed @types package to silence errors. That can create conflicts and let runtime-specific assumptions leak between browser, worker, and server code.
Avoid broad compatibility switches unless they are temporary, documented, and assigned a removal date. A migration that merely hides the warning will return as a harder TypeScript, Node, or npm upgrade later.
how to verify the result
Run tsc --showConfig and inspect compilerOptions.types, then type-check each project reference independently. Missing globals should be resolved without introducing unrelated ones.
Record the tool version and verification command in the pull request. That gives reviewers evidence and gives the next upgrade a known baseline.
rollout note
Ship the change in a small pull request that records the old behavior, the new behavior, and the rollback command. For an application, test the production image rather than only the developer machine. For a library, install the packed tarball in a tiny consumer project. Keep the previous lockfile or compiler configuration available until CI, deployment, and one real workflow have all passed.
That evidence makes the upgrade reviewable. It also prevents a later failure from being blamed vaguely on the entire major release when one setting or experimental flag was responsible.
official reference
Check the linked documentation again before upgrading production. Current-release features and announced security timelines can change in later patch releases.