6 ms·

TypeScript 6.0 RC

104 points by johnz 7mo ago

culi 7mo ago
For anyone who isn't aware, TypeScript does not use semantic versioning. Though TypeScript 7.0 will be significant in that it will use the new Go compiler
- tshaddox 7mo ago
  Semantic versioning seems slightly weird to even apply to something like TypeScript. You could have patch releases that fix actual compiler crashes, sure, but what is a minor release? Surely any new feature that causes code to fail to type check when it previously would pass (or vice versa) would have to be considered a breaking change. A similar thing applies to code formatting tools like Prettier, or any linter.
  - spankalee 7mo ago
    Semantic versions would at least be playing nice with how npm manages version ranges. If every release of TypeScript is breaking, then you should use major versions so that `npm update` doesn't break your project. Yes, typescript would be at version 60 now. No, that's not a problem at all. Numbers are free.
    - ukuina 7mo ago
      > Numbers are free. Someone please tell the LLM naming committee.
- joshkel 7mo ago
  Appreciate the reminder (the lack of SemVer has thrown me in the past). In this case, 6.0 is a bigger change than normal: > TypeScript 6.0 arrives as a significant transition release, designed to prepare developers for TypeScript 7.0, the upcoming native port of the TypeScript compiler. While TypeScript 6.0 maintains full compatibility with your existing TypeScript knowledge and continues to be API compatible with TypeScript 5.9, this release introduces a number of breaking changes and deprecations that reflect the evolving JavaScript ecosystem and set the stage for TypeScript 7.0.
pscanf 7mo ago
As a user, I'm of course very excited about v7. As a developer of an app that _integrates_ TypeScript, however, I feel a bit uneasy seeing the API feature still marked as "not ready" on the roadmap. On the other hand, I can understand leaving it as the last thing to do, after the foundation has set. Also, the TypeScript team has really done an amazing job all these years with backward compatibility, so that is extremely reassuring. Maybe my uneasiness is just impatience to get to use the sped-up version in my app as well! :)
- tanepiper 7mo ago
  FWIW I tried it with the VSCode preview in two monorepos we have - one frontend and one backend GraphQL servers with complex types - absolutely no issues (except one breaking change in tsconfig with baseUrl being removed) and fast compile times.
  - silverstream 7mo ago
    Same experience here with a pnpm workspace monorepo. The baseUrl removal was the only real friction — we were using it as a path alias root, had to move everything to subpath imports. The moduleResolution: node deprecation is the one I'd flag for anyone not paying attention yet. Switching to nodenext forced us to add .js extensions to all relative imports, which was a bigger migration than expected. Compilation speed improvement is real though. Noticeably faster on incremental builds.
- spankalee 7mo ago
  As a developer that integrates typescript into client-side web pages and writes lots of custom plugins, I'm extremely nervous about the port to Go. I think the last estimate I saw was the the Go port compiled to WASM was going to be about triple the size of the minified JS bundle.
tmaly 7mo ago
I had no idea they were using Go to write a compiler.
alembic_fumes 7mo ago
> strict is now true by default I would still have a full head of hair if this had been the case since the beginning. Nonetheless I am glad that we got here in the end.
- steve_adams_86 7mo ago
  I came to point that out too. What an awesome development. I think this will have a meaningful impact on the general quality of TS projects over the coming years.
  - deleted 7mo ago
    [deleted]
- 369548684892826 7mo ago
  Just use deno
  - paulddraper 7mo ago
    Exactly when do you think demo started.
- Analemma_ 7mo ago
  TypeScript never would’ve taken off if it had been strict from the beginning, it would’ve been just another forgotten gravestone next to Dart and CoffeeScript. I’m not saying those are bad languages, they’re not, but anything other than a very slow and gradual opt-in transition was just a non-starter. It was painful, but TypeScript played the long game.
  - paulddraper 7mo ago
    Many of the strict checks did not even exist when TS was first created.
    - romellem 7mo ago
mdtrooper 7mo ago
What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example: type Dog = { bark: () => void } type Cat = { meow: () => void } function speak(animal: Dog | Cat) { if (‘bark’ in animal) { animal.bark(); } else { animal.meow(); } } Okay, okay, I know you can filter using ‘in’ to see if it has methods, but in real life, in a company where you have a colleague (who is a golden boy) who writes over-engineered code with hundreds of interfaces of interfaces, you don’t want to spend time searching through the files to find every element that is in the union type. Whereas in Rust it does: struct Dog { name: String, } struct Cat { name: String, } enum Animal { Dog(Dog), Cat(Cat), } fn process_animal(animal: Animal) { match animal { Animal::Dog(dog) => { println!(‘It is a dog named {}’, dog.name); } Animal::Cat(cat) => { println!(‘It is a cat named {}’, cat.name); } } } I think TypeScript should add a couple of lines of code to the generated JavaScript to do something like: type Dog = { bark: () => void } type Cat = { meow: () => void } function speak(animal: Dog | Cat) { if (animal is Dog) { animal.bark(); } else { animal.meow(); } }
- tshaddox 7mo ago
  The idiomatic way to do this in TypeScript is with discriminated unions. You’re basically just giving the type system an extra property that makes it trivial to infer a type guard (while also making the runtime check in the compiled JavaScript foolproof).
  - culi 7mo ago
    This does act exactly as a discriminated union. The code works exactly as written.
- zem 7mo ago
  this post on union types versus sum types is worth a read (the tl;dr is that they both have their uses and one is not strictly better) https://viralinstruction.com/posts/uniontypes/ https://viralinstruction.com/posts/uniontypes/
jauntywundrkind 7mo ago
My deepest thanks to one @AlCalzone for stepping up to Opus port Decorators to tsgo. https://github.com/microsoft/typescript-go/pull/2926 https://github.com/microsoft/typescript-go/pull/2926 It would have been an affront to have a 6.0 that shipped without the means to work for so so many javascript frameworks/libraries. AlCalzone utterly saving the day. I also am so so so thankful that maybe perhaps after what felt like a never ending dolldrums, we may finally be getting decorator support in some browsers. What a colossal relief it will be to see the progress of the language become manifest.
- ukuina 7mo ago
  > Disclaimer: This is an entire day worth of Claude Opus tokens. I don't claim I understand how it works, but I did my best to direct Claude to minimize the baseline diffs, of which it removed quite a few. TypeScript allows entirely LLM-coded PRs?
CuriousRose 7mo ago
I am hoping that eventually there will be some agnosticism with the language server. Currently they all seem to rely on Node which in my opinion is rapidly being outclassed by Bun in terms of resource usage. It would be great to eventually be able to pick what runtime they use in VS Code/Cursor to reduce energy drain on my laptop when working on the go.
- djrenren 7mo ago
  The typescript language server (along with the rest of the compiler) is being rewritten in go for Typescript 7. This work has been going on in parallel with the work on 6.0. The go port has most features of 6.0 already and you can follow its progress and read more about it here: https://github.com/microsoft/typescript-go https://github.com/microsoft/typescript-go
  - CuriousRose 7mo ago
    Sure, but instead of waiting another year for this to be launched - with a beta version precaution and inevitable bugs - why not remove the limited hard-coded Node paths and references now and ship something 80:20?
    - djrenren 7mo ago
      If it’s a simple change, they might accept a PR. If it isn’t, well that’s your answer. Not worth allocating engineers for it.
ianberdin 7mo ago
No way I turn it on. Not a joke.
pjmlp 7mo ago
I would rather have seen C# Native AOT for the Typescript 7, alongside Blazor for the playground, but it is what is. Now when .NET team complains about adoption I get to point out Typescript 7's contribution repo. And yes I know the reasons, my nick is on the discussions, please also watch the BUILD session where they acknowledge having to rewrite the whole datastructures due to Go's weaker type system.
- lenkite 7mo ago
  Yeah, its strange that Microsoft is not dogfooding its own stuff. Even as an "enterprise" Go developer myself, I would have preferred that Typescript was written in C# - it keeps language ecosystems diverse. And ensures that C# continues to improve.

104 points by johnz 7mo ago

culi 7mo ago

For anyone who isn't aware, TypeScript does not use semantic versioning. Though TypeScript 7.0 will be significant in that it will use the new Go compiler

tshaddox 7mo ago
Semantic versioning seems slightly weird to even apply to something like TypeScript. You could have patch releases that fix actual compiler crashes, sure, but what is a minor release? Surely any new feature that causes code to fail to type check when it previously would pass (or vice versa) would have to be considered a breaking change. A similar thing applies to code formatting tools like Prettier, or any linter.
- spankalee 7mo ago
  Semantic versions would at least be playing nice with how npm manages version ranges. If every release of TypeScript is breaking, then you should use major versions so that `npm update` doesn't break your project. Yes, typescript would be at version 60 now. No, that's not a problem at all. Numbers are free.
  - ukuina 7mo ago
    > Numbers are free. Someone please tell the LLM naming committee.
joshkel 7mo ago
Appreciate the reminder (the lack of SemVer has thrown me in the past). In this case, 6.0 is a bigger change than normal: > TypeScript 6.0 arrives as a significant transition release, designed to prepare developers for TypeScript 7.0, the upcoming native port of the TypeScript compiler. While TypeScript 6.0 maintains full compatibility with your existing TypeScript knowledge and continues to be API compatible with TypeScript 5.9, this release introduces a number of breaking changes and deprecations that reflect the evolving JavaScript ecosystem and set the stage for TypeScript 7.0.

pscanf 7mo ago

As a user, I'm of course very excited about v7. As a developer of an app that _integrates_ TypeScript, however, I feel a bit uneasy seeing the API feature still marked as "not ready" on the roadmap. On the other hand, I can understand leaving it as the last thing to do, after the foundation has set. Also, the TypeScript team has really done an amazing job all these years with backward compatibility, so that is extremely reassuring. Maybe my uneasiness is just impatience to get to use the sped-up version in my app as well! :)

tanepiper 7mo ago
FWIW I tried it with the VSCode preview in two monorepos we have - one frontend and one backend GraphQL servers with complex types - absolutely no issues (except one breaking change in tsconfig with baseUrl being removed) and fast compile times.
- silverstream 7mo ago
  Same experience here with a pnpm workspace monorepo. The baseUrl removal was the only real friction — we were using it as a path alias root, had to move everything to subpath imports. The moduleResolution: node deprecation is the one I'd flag for anyone not paying attention yet. Switching to nodenext forced us to add .js extensions to all relative imports, which was a bigger migration than expected. Compilation speed improvement is real though. Noticeably faster on incremental builds.
spankalee 7mo ago
As a developer that integrates typescript into client-side web pages and writes lots of custom plugins, I'm extremely nervous about the port to Go. I think the last estimate I saw was the the Go port compiled to WASM was going to be about triple the size of the minified JS bundle.

tmaly 7mo ago

I had no idea they were using Go to write a compiler.

alembic_fumes 7mo ago

> strict is now true by default I would still have a full head of hair if this had been the case since the beginning. Nonetheless I am glad that we got here in the end.

steve_adams_86 7mo ago
I came to point that out too. What an awesome development. I think this will have a meaningful impact on the general quality of TS projects over the coming years.
- deleted 7mo ago
  [deleted]
369548684892826 7mo ago
Just use deno
- paulddraper 7mo ago
  Exactly when do you think demo started.
Analemma_ 7mo ago
TypeScript never would’ve taken off if it had been strict from the beginning, it would’ve been just another forgotten gravestone next to Dart and CoffeeScript. I’m not saying those are bad languages, they’re not, but anything other than a very slow and gradual opt-in transition was just a non-starter. It was painful, but TypeScript played the long game.
- paulddraper 7mo ago
  Many of the strict checks did not even exist when TS was first created.
  - romellem 7mo ago

mdtrooper 7mo ago

What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example: type Dog = { bark: () => void } type Cat = { meow: () => void } function speak(animal: Dog | Cat) { if (‘bark’ in animal) { animal.bark(); } else { animal.meow(); } } Okay, okay, I know you can filter using ‘in’ to see if it has methods, but in real life, in a company where you have a colleague (who is a golden boy) who writes over-engineered code with hundreds of interfaces of interfaces, you don’t want to spend time searching through the files to find every element that is in the union type. Whereas in Rust it does: struct Dog { name: String, } struct Cat { name: String, } enum Animal { Dog(Dog), Cat(Cat), } fn process_animal(animal: Animal) { match animal { Animal::Dog(dog) => { println!(‘It is a dog named {}’, dog.name); } Animal::Cat(cat) => { println!(‘It is a cat named {}’, cat.name); } } } I think TypeScript should add a couple of lines of code to the generated JavaScript to do something like: type Dog = { bark: () => void } type Cat = { meow: () => void } function speak(animal: Dog | Cat) { if (animal is Dog) { animal.bark(); } else { animal.meow(); } }

tshaddox 7mo ago
The idiomatic way to do this in TypeScript is with discriminated unions. You’re basically just giving the type system an extra property that makes it trivial to infer a type guard (while also making the runtime check in the compiled JavaScript foolproof).
- culi 7mo ago
  This does act exactly as a discriminated union. The code works exactly as written.
zem 7mo ago
this post on union types versus sum types is worth a read (the tl;dr is that they both have their uses and one is not strictly better) https://viralinstruction.com/posts/uniontypes/ https://viralinstruction.com/posts/uniontypes/

jauntywundrkind 7mo ago

My deepest thanks to one @AlCalzone for stepping up to Opus port Decorators to tsgo. https://github.com/microsoft/typescript-go/pull/2926 https://github.com/microsoft/typescript-go/pull/2926 It would have been an affront to have a 6.0 that shipped without the means to work for so so many javascript frameworks/libraries. AlCalzone utterly saving the day. I also am so so so thankful that maybe perhaps after what felt like a never ending dolldrums, we may finally be getting decorator support in some browsers. What a colossal relief it will be to see the progress of the language become manifest.

ukuina 7mo ago
> Disclaimer: This is an entire day worth of Claude Opus tokens. I don't claim I understand how it works, but I did my best to direct Claude to minimize the baseline diffs, of which it removed quite a few. TypeScript allows entirely LLM-coded PRs?

CuriousRose 7mo ago

I am hoping that eventually there will be some agnosticism with the language server. Currently they all seem to rely on Node which in my opinion is rapidly being outclassed by Bun in terms of resource usage. It would be great to eventually be able to pick what runtime they use in VS Code/Cursor to reduce energy drain on my laptop when working on the go.

djrenren 7mo ago
The typescript language server (along with the rest of the compiler) is being rewritten in go for Typescript 7. This work has been going on in parallel with the work on 6.0. The go port has most features of 6.0 already and you can follow its progress and read more about it here: https://github.com/microsoft/typescript-go https://github.com/microsoft/typescript-go
- CuriousRose 7mo ago
  Sure, but instead of waiting another year for this to be launched - with a beta version precaution and inevitable bugs - why not remove the limited hard-coded Node paths and references now and ship something 80:20?
  - djrenren 7mo ago
    If it’s a simple change, they might accept a PR. If it isn’t, well that’s your answer. Not worth allocating engineers for it.

ianberdin 7mo ago

No way I turn it on. Not a joke.

pjmlp 7mo ago

I would rather have seen C# Native AOT for the Typescript 7, alongside Blazor for the playground, but it is what is. Now when .NET team complains about adoption I get to point out Typescript 7's contribution repo. And yes I know the reasons, my nick is on the discussions, please also watch the BUILD session where they acknowledge having to rewrite the whole datastructures due to Go's weaker type system.

lenkite 7mo ago
Yeah, its strange that Microsoft is not dogfooding its own stuff. Even as an "enterprise" Go developer myself, I would have preferred that Typescript was written in C# - it keeps language ecosystems diverse. And ensures that C# continues to improve.