TypeScript 6.0 beta: new defaults, many deprecations and the bridge to TypeScript 7

On February 11, Microsoft published the TypeScript 6.0 beta. It is worth being clear that this is a beta, not the final release, but it already shows what is coming. And what is coming is a transition release: according to the announcement, 6.0 is meant to be the last release based on the current JavaScript codebase. TypeScript 7.0 will be built on a native compiler written in Go. Version 6.0 exists, in large part, to prepare projects for that jump.

To try it:

npm install -D typescript@beta

The new defaults

The change that will show up most in real projects is the switch in compiler defaults:

• strict becomes true;
• module becomes esnext;
• target becomes the latest ECMAScript version, currently es2025;
• noUncheckedSideEffectImports becomes true;
• libReplacement becomes false;
• types becomes [];
• rootDir becomes the directory containing tsconfig.json.

The types default is the one most likely to break builds. Previously, TypeScript automatically included installed @types packages; now many projects will need to explicitly declare something like "types": ["node"]. If your project suddenly cannot find process or Buffer, this is why.

Making strict the default is, in my opinion, the right change and an overdue one. Almost every new project already turns on strict; now the zero-config behavior reflects how TypeScript is actually used.

New features

Some practical additions:

• Subpath imports with #/ work with moduleResolution node20, nodenext and bundler.
• --moduleResolution bundler can be combined with --module commonjs, which helps projects that still emit CommonJS but use a bundler.
• --stableTypeOrdering makes type ordering match TypeScript 7.0, to make comparisons easier during migration. The announcement warns that the flag can slow type-checking by up to 25% and is not meant as a permanent setting.
• es2025 as target and lib, with types such as RegExp.escape.
• Temporal types via esnext or temporal.esnext (the proposal is at stage 3).
• getOrInsert and getOrInsertComputed on Map and WeakMap, in the esnext lib.
• The contents of dom.iterable and dom.asynciterable are now part of dom; those two lib files are now empty.

The deprecation list

This is the heart of 6.0. Deprecated or removed:

• target: es5 and --downlevelIteration;
• --moduleResolution node (node10) and classic (removed);
• --module amd, umd and systemjs;
• baseUrl and outFile (the latter removed);
• setting esModuleInterop or allowSyntheticDefaultImports to false, and alwaysStrict: false;
• the module keyword for namespaces, asserts on imports (replaced by with) and the no-default-lib directive.

CLI behavior changes too: passing files on the command line when a tsconfig.json exists now raises error TS5112. To skip the config, use --ignoreConfig.

You can silence the deprecations in 6.0 with "ignoreDeprecations": "6.0". But that only postpones the problem: TypeScript 7.0 removes these options entirely.

How I would prepare

In practice, 6.0 is a dress rehearsal for 7.0. My suggestion:

1. Install the beta on a branch and run type checking without ignoreDeprecations, to see the real list of problems.
2. Declare types explicitly in tsconfig.json.
3. Replace baseUrl with subpath imports or relative paths, and move off moduleResolution node.
4. If you still depend on es5 or outFile, start planning your exit now, because there will be no version 7 with them.

My take

TypeScript 6.0 is a release few people will find exciting, and that is fine. Its value lies in doing the boring work before the native compiler arrives: cleaning up legacy options, aligning defaults with real-world usage and offering tools like --stableTypeOrdering to compare results. Teams that treat 6.0 as the moment to tidy up their tsconfig will have a smooth migration to 7.0. Teams that just flip ignoreDeprecations and move on will pay the bill later, with interest.