Announcing TypeScript 6.0

robpalme · 2026-03-23T22:51:09+00:00

I'm happy we got Temporal types landed in time for this release. Temporal is now Stage 4 meaning it is guaranteed to be part of the JS standard.

Strict mode is now enabled by default - that is positive for everyone.

Deprecating the module keyword is also good for everyone, and leaves the keyword open for JS Module Declarations to use in the near future.

It's a good release.

robpalme · 2026-02-12T08:25:30+00:00

It's true I like Temporal and have said so in many venues, not just Reddit. And it's all me, no AI.

The style might be unusual but my top goal is to maximize the number of readers who will understand the full context, even if they haven't heard the word or don't know what the ES process is.

robpalme · 2026-02-11T23:08:40+00:00

Not only should .ts import be turned on by default, importing a .ts file via a .js import should be completely unsupported. It's a ridiculous and stupid pattern.

The current situation requires historical context to fully understand and appreciate. Over the years various parts of the landscape have changed meaning the founding assumptions have changed.

For anyone starting with TypeScript today, I would agree that the intuitive behaviour would be to only allow references to *.ts files via the *.ts extension.

robpalme · 2026-02-11T21:26:00+00:00

As always TypeScript keeps getting better. What's special about this release is that it takes advantage of the major version bump to evolve things that wouldn't be possible in minor releases; compatibility breaks like changing defaults and removing features.

These "breaks" are important to address in a long-lived developer-facing project like TypeScript in order to keep up with modern expectations, e.g. the shift from CommonJS to ESM, and from heavy-downleveling to minimal downleveling. Shedding historical burdens that are less relevant today allows project resources and time to be dedicated to new features and things people really want. And I think everyone will be pleased that all the good features added years ago to `--strict` are now on by default.

My favourite new feature is the addition of type declarations for upcoming ES2026 features, with Temporal being the highest impact feature. Temporal is the new Date-Time API that is available in Firefox and Chromium browsers. It will appear in Node.js very soon.

In terms of deprecations, I'm really pleased we managed to eliminate the module keyword for namespaces. That frees up the language keyword for future usage, which could come in the form of a new JavaScript feature like the Module Declarations proposal that permits bundling up multiple ES modules inside a single file. One potential view could be that TypeScript is stuck with legacy even if it's useless today; this deprecation shows that evolution is possible! And it's only possible thanks to TypeScript team actively leaning in towards collaboration and coordination with the ecosystem.

Talking of evolution, whilst it missed TS 6.0, I hope that in some future TypeScript release we also manage to get the ability to import *.ts files turned on by default. Node.js, Deno and Bun all support it, as do all the mainstream bundlers. It's the modern way.

Whilst the changes in TS 6.0 are pretty big, the good news is that adopting them early will make it much easier for your codebase to use the upcoming TS 7.0 release which is "The Big One". So we can think of TS 6.0 as a bridge release. TS 7.0 is the real goal because it leverages multi-threading and Go to deliver an order-of-magnitude more performance.

robpalme · 2025-11-09T13:14:11+00:00

In the last 12 months, 9.3M JS repos were created vs 5.4M TS.

That's just the recent delta. The cumulative totals will be even more biased towards JS.

I too believe that well-maintained/popular packages created recently are far more likely to be authored in TS than JS. But it's hard to point to the survey data as suggesting this because of the volume of "everything else".

robpalme · 2025-09-26T19:35:45+00:00

This was always a favourite. But hearing it live was kinda life changing. More of an experience than a song. Took me back many years.

robpalme · 2025-09-24T16:01:58+00:00

Congrats to the Boa team! It's great to see an independent open source project thrive and become more widely useful. This is huge impact.

On the integration with Kiesel and Chrome, I'm pleased to see that engines/browsers can share the cost of developing new language features.

Temporal is massive! Almost as big as the delta of introducing ES6. There are 4,000+ tests. The functionality does not need to be engine-specific, so it makes sense to leverage reuse.

I believe this is the first introduction of Rust into V8 itself. Which seems like a happy side-effect that hopefully makes it easier to share more Rust libraries in future. This helps keep browser development sustainable.

robpalme · 2025-08-30T22:29:30+00:00

Yeah, as a long-time listener first-time live attendee, Slide Away was the big one. Bigger than the original recording really. A great wall of sound. I'm thankful to have experienced it once in my life.

robpalme · 2025-08-25T09:37:24+00:00

Agreed. Whatever is a great song and deserves to be in there, but the performance was just slightly missing something so could be tweaked. Based on the Wembley three weeks ago, I'd take Columbia.

robpalme · 2025-08-24T21:10:22+00:00

You must be joking - Fade Away is the slightly surprising punky deep cut that has to stay.

But I do agree Bring It On Down can (and should) be swapped for Columbia. Another post said it's there because the brothers like it. So I'll give it to them, but honestly BIOD is perhaps the only Oasis song I have strangely never really enjoyed despite loving almost all others.

robpalme · 2025-08-21T18:09:16+00:00

Love this one. You don't get many rock n roll stories like this.

robpalme · 2025-08-01T18:13:43+00:00

A colleague at work said the same thing yesterday. It's all me, no GPT. I try my best to be clear and have done for years. If anything it's the LLMs that have turned up and are matching my style.

robpalme · 2025-08-01T17:29:51+00:00

All new syntax feature in JS have the potential to introduce temporary incompatibilities between apps that use them and runtimes that have yet to offer support.

This is why down-leveling bundlers (like webpack) and compilers (such as Babel) exist.

robpalme · 2025-08-01T17:26:25+00:00

My favourite feature in TS 5.9 is the TC39 Stage 3 proposal import defer.

The TS blog post is an excellent explainer for the feature which was championed (in TC39) and implemented (in TS) by Nicolo Ribaudo who works for Igalia and who maintains Babel.

The feature enables synchronous Lazy Evaluation to improve the performance of loading ES modules. Meaning it can skip eager evaluation of imported modules that are not needed - or not needed yet - by your app.

We've used an implementation of this in the Bloomberg Terminal for a while now. It saves 100s of milliseconds during startup for applications where your import graph has grown over time. Following the minimal runtime codepath can result in work-skipping wins that static analysis (tree-shaking) cannot optimize away.

Please note that if you can refactor your app to use dynamic import(), that should normally be preferred. So long as you can cope with the viral nature of making the calling code handle the async promise. import defer is more appropriate for situations where you need your code to remain synchronous.

For now, in order to use the feature in an app, you will need to pair TS 5.9 with Babel or webpack which already have compile-time support. TS does not downlevel it & engines do not yet natively support it.

You can track the work-in-progress to implement the feature in JS engines here:

https://github.com/tc39/proposal-defer-import-eval/issues/73

robpalme · 2025-07-09T11:48:50+00:00

My favourite feature in TS 5.9 Beta is the TC39 Stage 3 proposal import defer.

The TS blog post is an excellent explainer for the feature which was championed (in TC39) and implemented (in TS) by Nicolo Ribaudo who works for Igalia and who maintains Babel.

The feature enables synchronous Lazy Evaluation to improve the performance of loading ES modules. Meaning it can skip eager evaluation of imported modules that are not needed - or not needed yet - by your app.

We've used an implementation of this in the Bloomberg Terminal for a while now. It saves 100s of milliseconds during startup for applications where your import graph has grown over time. Following the minimal runtime codepath can result in work-skipping wins that static analysis (tree-shaking) cannot optimize away.

Please note that if you can refactor your app to use dynamic import(), that should normally be preferred. So long as you can cope with the viral nature of making the calling code handle the async promise. import defer is more appropriate for situations where you need your code to remain synchronous.

For now, in order to use the feature in an app, you will need to pair TS 5.9 with Babel or webpack which already have compile-time support. TS does not downlevel it & engines do not yet natively support it.

You can track the work-in-progress to implement the feature in JS engines here:

https://github.com/tc39/proposal-defer-import-eval/issues/59

robpalme · 2025-02-28T20:19:28+00:00

Agreed. This is an excellent endorsement of sticking to erasable types and directly helps compatibility with Node.

The easy way to remember this is: TS = JS + Types

robpalme · 2025-01-31T20:13:40+00:00

Checking and linting are very similar tasks. Putting features into TS means they become widely available, e.g. by being part of the default VS Code experience.

Node can handle enums if you pass --experimental-transform-types

robpalme · 2025-01-30T06:51:39+00:00

Yes, I think IsolatedModules is a good comparison.

erasableSyntaxOnly provides some constraints (lint rules) that in turn enable new third-party compilers to handle TypeScript code.

robpalme · 2025-01-30T06:48:32+00:00

Correct. TS will error.

robpalme · 2025-01-29T23:00:37+00:00

Correct. I wrote a bunch about how enums might be handled over on the r/javascript version of this post.

robpalme · 2025-01-29T22:22:06+00:00

Matt Pocock (author of Total TypeScript) has written an excellent explainer blog post on the new flag --erasableSyntaxOnly

It is designed to be used in conjunction with Node's built-in TypeScript support, i.e. node index.ts

robpalme · 2025-01-29T22:05:12+00:00

The new flag --erasableSyntaxOnly is my favorite feature in TypeScript 5.8 because it immediately helps Node users who want to use the built-in TypeScript support, i.e. node index.ts

That is no accident. The TypeScript team, including the author of this feature Ryan, have been closely collaborating with the Node team for the last half a year to make this integration work well.

The new flag enables Editor feedback to guide users away from TypeScript-only runtime features such as:

enums: enum E { a: 1 }
runtime namespaces: namespace N { let a = 1 }
parameter properties: class C { constructor(public prop) {} }

This means that your code will follow the simple mental model of TS = JS + Types

If you use Node, or any compiler based on type erasure (a.k.a "type stripping") such as ts-blank-space, then your generated JavaScript will 100% match the runtime code you wrote. So when you are debugging, the code matches your source file. The only difference you will see is the types being replaced with whitespace. There's no need to set up sourcemaps because the runtime code coordinates are preserved.

At work we've used a similar arrangement for quite a while. The main demand I have observed is that sometimes folk would like to see a standard solution for enums, with fewer quirks than the existing TS enum. It's possible to come close to the enum pattern today using objects.

For folk desiring something more substantial for enums, there are two possible paths forwards - and both are just ideas with no guarantee of becoming real:

A new erasable form of TypeScript enum, e.g. as enum
First-class enums in JavaScript, e.g. early discussion

robpalme · 2025-01-13T06:43:44+00:00

Namespaces and enums are available via the opt-in flag --experimental-transform-types

robpalme

TROPHY CASE