What's New in TypeScript 6.0

TypeScript 6.0 shipped in March as a transitional release ahead of the Go-rewritten 7.0. 6.0 prepares projects for that move.

Most of the changes are about flipping defaults and removing old options. The new defaults already match how most teams set up new projects. Older codebases will feel a few of these.

Strict mode is on by default

New TypeScript projects are now strict by default, which is the largest change in this release. The compiler catches mistakes that previously needed an opt-in flag, like accessing properties on values that might be undefined, or implicit any types where you forgot to annotate something.

Most teams already turned this on manually, so making it the default removes a setup step.

Modern compile targets by default

Three defaults moved at once:

• target is now es2025, not es5. TypeScript no longer assumes it has to compile down to a 2009 version of JavaScript.
• module is esnext, not commonjs. ESM is the default module format.
• The old es5 target is deprecated entirely.

If you’re shipping to modern Node or modern browsers, you don’t have to think about any of this. If you’re targeting older runtimes, you’ll need to set the target explicitly.

A pile of old options removed

TypeScript has accumulated configuration options for over a decade. 6.0 prunes a lot of them:

• --moduleResolution node (the original Node resolution) is deprecated. Use nodenext or bundler.
• --moduleResolution classic is gone.
• --module amd|umd|systemjs are removed. Projects still emitting AMD or SystemJS modules can’t use 6.0 without changing their build output.
• --outFile is removed. Use a real bundler.
• --baseUrl is deprecated in favour of explicit path mappings.
• --downlevelIteration is gone, since there’s no es5 target to downlevel to.

The old options stuck around for years past their usefulness because TypeScript takes backwards compatibility seriously. 6.0 is the cleanup pass.

Shorter import paths

Node’s subpath imports now support #/* directly. Previously you’d write something like "#root/*": "./dist/*" in your package.json. Now you can write "#/*": "./dist/*" and import with #/foo. It replaces relative paths like ../../../components/foo with #/components/foo.

New JavaScript features get types

TypeScript 6.0 ships types for the latest ECMAScript additions:

• Temporal, the replacement for JavaScript’s Date object, is now Stage 4 and has built-in types.
• RegExp.escape() for safely escaping user input into regex patterns.
• Map.getOrInsert() and Map.getOrInsertComputed(), which replace the common pattern of “check if key exists, set default if not.”
• Promise.try() for wrapping a function call into a promise without the try/catch dance.

These are JavaScript features, not TypeScript ones. But TypeScript shipping the types is what makes them usable in typed codebases without writing your own definitions.

Getting ready for 7.0

The headline feature of TypeScript 7.0, due later this year, is that the compiler has been rewritten in Go. The benchmarks Microsoft has shared show roughly 10x faster type-checking on large codebases.

6.0 is the version that prepares you for that move. There’s a new --stableTypeOrdering flag that matches how 7.0 will order types deterministically, so your generated .d.ts files don’t churn between versions. There’s a @typescript/native-preview npm package if you want to try the Go version now.

Microsoft’s guidance is to clear any 6.0 deprecation warnings before upgrading to 7.0.

What to do

For most teams, the upgrade involves bumping the version, reading the warnings, and setting "types": ["node"] and "rootDir": "./src" if your config was relying on inference.

For older codebases that depend on outFile, AMD modules, or the original Node resolution, you’ll need to do real work. Those projects had the migration coming once 7.0 lands, and 6.0 sets a fixed point for it.