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 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.
SOCIAL SHARE CARD GENERATOR