TypeScript 6.0 Flipped Your Defaults. TypeScript 7 Will Remove Them.

Verified as of 12 August 2026. Version numbers and release dates below reflect the best available reporting at the time of writing. Confirm against the official TypeScript release notes before planning a migration.

The short version

TypeScript 6.0 shipped in March 2026. It is not a routine minor bump. It changed defaults that a great many codebases quietly depended on, and it deprecated compiler options that 7.0 is expected to remove outright.

The deprecation warnings you are seeing now are the migration window. Once 7.0 lands, they become build failures.

What 6.0 actually changed

Three categories of change, in rough order of how much work they cause.

Flipped defaults

The headline change is that 6.0 turned on settings most projects previously had to opt into - including strict type checking and modern ES module resolution as defaults.

If your tsconfig.json was explicit about these, nothing happens. If you relied on the old implicit defaults, upgrading surfaces every latent type error in the codebase at once. On a large project this is not a small number.

Practical approach: do not upgrade and fix simultaneously. Pin to 5.x, set the 6.0 defaults explicitly in your existing config, and fix the fallout under the compiler you already know. Then upgrade, which becomes a no-op.

1// Step 1: adopt 6.0's defaults explicitly while still on 5.x.
2// The upgrade then changes nothing, because you already comply.
3{
4  "compilerOptions": {
5    "strict": true,
6    "module": "esnext",
7    "moduleResolution": "bundler"
8    // ...your existing options
9  }
10}

Deprecations aimed at 7.0

Several options are deprecated in 6.0 with removal signalled for the next major. outFile is the one most likely to bite, because the projects still using it tend to be the oldest and least actively maintained - exactly the codebases with the least slack for a migration.

If you are bundling via outFile, that path is closing. Move to a real bundler.

Built-in library updates

6.0 pulled in types from the current ECMAScript specification. Mostly beneficial, occasionally a conflict if you shipped your own declarations for something that now exists natively. The symptom is a duplicate-identifier error in code you have not touched.

Why 7.0 matters more than the version number suggests

TypeScript 7.0 is expected to introduce a compiler implemented natively in Go, replacing the JavaScript-hosted compiler that has served since the beginning.

This is a genuinely large change, and it reframes the 6.0 deprecations. A native port is a strong reason to shed compatibility surface: every legacy option is code that has to be reimplemented and kept behaviourally identical. Options marked for removal in 6.0 are unlikely to survive that process.

The upside for anyone who has waited out a slow tsc on a large monorepo needs little explanation. The condition for getting it is a config that does not depend on removed options.

Node.js 24 changes the surrounding picture

Worth folding into the same planning cycle: Node.js 24 arrived in early 2026 with a notably large expansion of built-in surface area. Reported additions include TypeScript support moving from an experimental flag to default behaviour, a native glob API, SQLite as a built-in module, a compile cache, a WebSocket client, and a maturing test runner.

The practical consequence is dependency reduction. Several of the most-downloaded packages in a typical package.json now have runtime-native equivalents. If you are already touching build configuration for the TypeScript migration, it is a reasonable moment to audit what the runtime now does for you.

One caution: "Node supports TypeScript" means type-stripping execution, not type checking. You still need tsc - or an equivalent - in CI. Running unchecked TypeScript directly and calling it a build is a category error we expect to see a lot of.

A migration order that works

1. Get to the latest 5.x first. Do not jump versions with unresolved warnings.
2. Turn on the 6.0 defaults explicitly, still on 5.x. Fix errors under a compiler whose behaviour you already understand.
3. Clear every deprecation warning. Treat each one as a 7.0 build failure with a grace period.
4. Migrate off outFile. This is the item most likely to need real architectural work. Start it early.
5. Upgrade to 6.0. If steps 2-4 are done, this should be uneventful.
6. Audit dependencies against Node's built-ins. Separate change, convenient timing.
7. Then evaluate 7.0. With a clean config, adopting the native compiler becomes a performance win rather than a project.

Where we would not assert confidence

The precise 7.0 removal list is not something to plan against as though it were final; deprecation sets shift between announcement and release. The direction of travel is clear and well-signalled. The exact contents are not, and anyone telling you otherwise is guessing.

React, for its part, is no longer the variable it was. React 19 shipped in December 2024 and is now the baseline rather than the migration - Actions, the use API, ref as an ordinary prop, and stable Server Components are all settled ground.

Sources

• React 19 upgrade guide - react.dev
• TypeScript v6 migration guide - LogRocket
• Node.js 24 feature summaries, cross-checked across release write-ups