Mastering the Latest TypeScript: What's New in 6.0 (and a Peek at 7)

TypeScript 6.0 has been out for a few months now, and it's a bit of an unusual release. It's the last compiler that will be written in TypeScript and JavaScript. Later this year, TypeScript 7 arrives with the compiler rewritten in Go. Microsoft has seen roughly 10x speed improvements on large codebases. That makes 6.0 the bridge release.

The good news is that the features I want to show you aren't going anywhere. Everything here is forward compatible with TypeScript 7. They're also just genuinely nice to use. I'll walk through five additions worth adopting today, show the tsconfig.json changes that add them, and finish with what the Go rewrite means for you.

If you'd rather watch than read, the full video is here.

Prerequisites

• Node.js 20 or newer
• TypeScript 6.0 (npm install -D typescript@6)
• A code editor with TypeScript support (I'm using Kiro)
• Basic familiarity with tsconfig.json

1. Native Temporal date and time types

The built-in JavaScript Date API isn't that great. Months are zero-indexed, time zone handling is painful, and most of us reach for an API library to help. TypeScript 6 ships type support for Temporal, the TC39 date/time API, so you get a modern API with no extra dependency.

Creating a date is readable now. You pass the year, month, and day as named fields instead of memorizing argument order.

const launch = Temporal.PlainDate.from({ year: 2026, month: 9, day: 1 });

// Arithmetic that reads the way you think about it
const twoWeeksLater = launch.add({ weeks: 2 });
const aMonthEarlier = launch.subtract({ months: 1 });

Time zones are really neat to use. You can format the same instant across several zones without juggling offsets by hand.

const now = Temporal.Now.zonedDateTimeISO("America/Los_Angeles");

const zones = ["America/Los_Angeles", "America/New_York", "Europe/London", "Asia/Tokyo"];
for (const zone of zones) {
  const local = now.withTimeZone(zone);
  console.log(zone, local.toLocaleString());
}

And duration math, the thing that usually sends you to a library, is built in.

const today = Temporal.Now.plainDateISO();
const target = Temporal.PlainDate.from("2026-09-01");
const diff = today.until(target, { largestUnit: "day" });

console.log(`${diff.days} days until launch`);

You get all this without a date library, and you avoid the off-by-one month bugs that Date gives you. This is the feature I expect people to adopt first.

2. Map.getOrInsert() and getOrInsertComputed()

If you work with Map, you know the check-then-set code you have to write. You want to insert a value only if the key isn't already there, so you write something like this.

const cache = new Map<string, number>();

if (!cache.has("a")) {
  cache.set("a", 1);
}
const value = cache.get("a")!; // non-null assertion because get() can return undefined

Two things bother me there. The if guard is boilerplate, and the ! non-null assertion exists only because get() is typed to possibly return undefined. TypeScript 6 adds Map.getOrInsert(), which adds all of that into one call.

const cache = new Map<string, number>();

const value = cache.getOrInsert("a", 1); // returns 1, inserts if missing
cache.getOrInsert("a", 99);              // key exists, so this is ignored
console.log(cache.get("a")); // still 1

It checks for the key, returns the existing value if present, and inserts only when the key is missing. You don't overwrite anything, and the guard and the assertion both go away.

There's a companion method, getOrInsertComputed(), that takes a factory function instead of a value. The function only runs when the key is actually missing.

const cache = new Map<string, number>();

cache.getOrInsertComputed("a", () => {
  console.log("computing a");
  return 1;
}); // logs "computing a", inserts 1

cache.getOrInsertComputed("a", () => {
  console.log("this never runs");
  return 2;
}); // key already exists, so the factory is skipped entirely

That second factory never executes. If your value is expensive to produce, a database call, a heavy calculation, parsing something large, getOrInsertComputed() skips the work entirely when the key already exists. getOrInsert() evaluates its argument no matter what, so reach for the computed version when the value isn't cheap.

3. RegExp.escape() for safe dynamic regex

Building a regular expression from user input is a classic problem that we all run into. Say you take a version string and try to match it.

const userInput = "1.0";
const pattern = new RegExp(userInput, "g");

const text = "version 1.0 and build 1x0 are different";
console.log(text.match(pattern)); // matches BOTH "1.0" and "1x0"

That matches more than you wanted. The . in the input is a regex wildcard, so it matches any character, including the x in 1x0. TypeScript 6 adds RegExp.escape(), which escapes special characters in a string so it's treated literally.

const userInput = "1.0";
const pattern = new RegExp(RegExp.escape(userInput), "g");

const text = "version 1.0 and build 1x0 are different";
console.log(text.match(pattern)); // matches only "1.0"

Now the dot is a literal dot, and you match exactly what you meant. Any time you build a regex from a value you didn't write yourself, wrap it in RegExp.escape().

4. The # subpath imports (and the tsconfig that powers them)

Deep relative imports like ../../../utils/format are hard to read and break when you move files. The common fix is a path alias with @, but that can collide with real npm packages, since plenty of scoped packages start with @. TypeScript 6 leans into Node's subpath imports, which use a # prefix that can't be confused with a package name.

Setup happens in two files. First, tsconfig.json needs a module resolution mode that understands subpath imports.

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler"
  }
}

If you're not using a bundler, the Node-native equivalent works too.

{
  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext"
  }
}

Then you declare the actual mapping in package.json under imports.

{
  "imports": {
    "#utils/*": "./src/utils/*.js",
    "#components/*": "./src/components/*.js"
  }
}

Now your imports are clean.

import { formatDate } from "#utils/format";
import { Button } from "#components/Button";

Without one of those module resolution settings, the # imports won't resolve, so the tsconfig change is the part that actually unlocks the feature. If you watched my earlier video on tsconfig paths, this is the modern, standardized version of that same idea.

5. Smarter generic inference

This one removes annotations you used to have to write by hand. Take a generic interface like this.

interface CreatePair<T> {
  config: { value: T };
  consume: (value: T) => void;
}

Before TypeScript 6, you usually had to pin the generic explicitly when you used it.

const pair: CreatePair<number> = {
  config: { value: 42 },
  consume: (value) => console.log(value),
};

TypeScript 6 infers T from the value you provide, so the annotation becomes optional.

const pair = {
  config: { value: 42 },        // T inferred as number
  consume: (value: number) => console.log(value),
};

Because the compiler reads 42 and figures out the type, you write less and still get full type safety and autocomplete everywhere. It's a small change you'll feel constantly in real code.

tsconfig.json changes worth making now

Beyond the subpath imports config above, TypeScript 6 shifts a few defaults in a direction that TypeScript 7 will push as well. A few minutes auditing your config today saves friction later.

• strict now defaults to true. If you've explicitly set strict: false, you're working against where the language is heading. This is a good moment to enable it or write down why you're opting out.
• verbatimModuleSyntax: true is encouraged and replaces the older importsNotUsedAsValues. It forces explicit import type for type-only imports, which keeps your emitted output predictable.
• baseUrl is no longer required for paths to work. If you only kept baseUrl around to enable path aliases, you can drop it.
• moduleResolution: "node" is on its way out. If you're still on the legacy resolver, 6.0 is the time to move to nodenext or bundler.

What's coming in TypeScript 7

TypeScript 7 is the headline behind all of this. The compiler is being rewritten in Go (the project codename is Corsa), and the speed gains look impressive. The Go compiler parallelizes across CPU cores, so the bigger your codebase, the more you benefit.

Wrapping up

TypeScript 6 isn't a flashy release, and that's the point. Temporal, the new Map methods, RegExp.escape(), subpath imports, and smarter inference all make day-to-day code a little cleaner, and none of it gets in your way when you move to 7. The single most valuable thing you can do today is adopt these APIs and audit your tsconfig.json so the Go-compiler upgrade is a non-event.

I also built an experimental skill that helps you upgrade older TypeScript projects to 6.0. If you use Kiro, Claude Code, or another agentic editor, give it a try on a TypeScript 5 project and let me know how it goes. The link is in the video description.

Watch the full walkthrough on YouTube, and drop a comment if you've started using any of these in your own projects.