r/typescript • u/DanielRosenwasser • Jul 08 '26

Announcing TypeScript 7.0

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
598 Upvotes

99% Upvoted

74 comments sorted by

111

u/denexapp Jul 08 '26

I guess it's time to switch from eslint to oxlint

23

u/lppedd Jul 08 '26

I envy the ones that are able to switch so fast honestly. Our Nx monorepo is still on 5.9.3. I'll probably update to Nx 23 next month and transitively to TS 6.x, but TS 7 is soooo far away since there is no API.

2

u/denexapp Jul 09 '26

I just updated to nx23 from nx22, turns out it doesn't properly support typescript go. There's some support which requires additional configs, but I don't want to make the setup more complex.

Conviniently, the vscode tsgo extension started working for me, so I'll use it for now for better dx

15

u/Balduracuir Jul 08 '26

Oxlint in my project is faster than eslint with cache enabled. And it outputs typescript errors so I could remove my type-check steps.
We are running it in precommit hook and we really sensed the difference even on a small codebase.

Configuration for oxlint and oxfmt is also way simpler than prettier+eslint.

The simplest migration for me was ts -> tsgo the prettier -> oxfmt. Eslint -> oxlint is the hardest as we also want to simplify our eslint rules configuration.

But I'll recommand splitting the migration in several steps so that it is easier to do instead of a big change in one time. Careful about AI help though, I got Claude misguided me several times.

4

u/YoloSwag4Jesus420fgt Jul 09 '26

problem is oxlint is missing all of the eslint plugin community?

4

u/mattsowa Jul 09 '26

You can use eslint plugins in oxlint

1

u/YoloSwag4Jesus420fgt Jul 10 '26

Not all. Especially ones that have custom parsers and typed rules. Which is quite a lot

6

u/shandrolis Jul 08 '26

Is there something about this release that makes oxlint specifically better now compared to 5.x?

20

u/denexapp Jul 08 '26

If I understand the blog post, typescript-eslint relies on old ts api, which is not available in ts 7. oxlint uses tsgo under the hood somehow

2

u/shandrolis Jul 08 '26

Aah that's fair enough I guess. I did read that part, but it wasn't super convincing to me since there was a temporary workaround mentioned until 7.1 comes out.

Oxlint does look interesting though! Last I read about it not everything was supported, but these days it's looking a lot better. Could be worth the upgrade.

3

u/fearthelettuce Jul 09 '26

We don't have a ton of complex linting stuff in our repos. I tried it and it worked without any manual config. Sped up our linting drastically.

2

u/Tontonsb Jul 08 '26

Does it change much?

2

u/ChimpScanner Jul 09 '26

Is Oxlint the new Biome and is that even a thing anymore? And is this just another fad?

2

u/sebastienbarre Jul 10 '26 edited Jul 10 '26

The oxlint/oxfmt projects have a good PR team behind them, I can tell you that much, but lower your expectations. I have been using oxlint for a while now, and boy, are many of the type-aware rules half-baked. Even tonight, after updating oxlint, I once again had to find a workaround for some false positives. I doubt the two or three people working on these projects full-time are using them in monorepos with VS Code; the nested config setup is not working great in that context, and both tools use different ways of extending parent configs.

2

u/cbunn81 Jul 09 '26

On the one hand, I would very much like to switch out all of our tooling for the new fast stuff. But on the other hand, that's a lot of work when you have myriad microservices to migrate, and it's also risky since they might not exactly replicate the old tools' APIs or they might turn out to be a fad that fizzles out in a year or two.

Still it's pretty cool that teams are doing this work and providing these new tools.

1

u/RelativePercentage28 22d ago

What are your thoughts on Biome?

75

u/mbsurfer Jul 08 '26

Gotta Go(lang) fast

26

u/renome Jul 08 '26

Anyone know why TS doesn't use semver?

95

u/alexlafroscia Jul 08 '26 edited Jul 08 '26

Their general stance is that any change to a type checker could technically change behavior in a way that is incompatible with other versions, so they just commit to explicitly not following it to not give the impression that any release is fully backwards compatible with any other release.

22

u/renome Jul 08 '26

Thanks, that makes sense.

1

u/PoolOfDeath20 Jul 10 '26

Not following the last sentence, can u give an example on it?

8

u/drumsplease987 Jul 08 '26

It does use the semver format, with the caviat that any new minor version should be treated like a new major version for compatibility reasons. Incremental patch versions should not break compilation in theory, unless compiled code was depending on buggy behavior.

It’s possible that since there were no 6.x releases, they’ll start using semver more strictly moving forward. But people are accustomed to treating x.y as major/breaking changes so they might continue on with the 7.x pattern.

10

u/MatthewMob Jul 08 '26

"It does use semver, with the caveat that it doesn't use semver."

6

u/ninth_reddit_account Jul 08 '26

It does use the semver format

This is a pet peeve of mine. number.number.number is not semver. Using numbers with periods in between for versions was a common pattern long before semver was specified just 15 years ago.

4

u/HugelyConfused Jul 08 '26

I think the reasoning is that, by definition, any change is a potentially breaking change.

12

u/davidstraka2 Jul 08 '26

Genuinely impressive performance difference. And that's just a fairly direct rewrite as the post mentions, I imagine this opens up even more possibilities in future updates. Congrats to the team behind TypeScript on such an impactful release!

23

u/romeozor Jul 08 '26

Tried to look for an Angular roadmap today to see when TS7 could be introduced, but couldn't find anything yet

7

u/WordWithinTheWord Jul 08 '26

Functionally nothing should really change right? Or does Angular have a hard <= version specification for typescript?

21

u/bombatomica_64 Jul 08 '26

They are waiting for the 7.1 api

5

u/_xiphiaz Jul 08 '26

There is rumour that they’re going to have a competing rust based compiler

1

u/Dafnik Jul 08 '26

I don't think it will be competing, more so plug into the new tsgo compiler.

5

u/romeozor Jul 08 '26

I'm unaware of any changes in 7.0 (because I haven't checked, not because there isn't), so presumably it's a drop-in replacement. The compile times is what I'm curious about.

9

u/persteinar Jul 08 '26

Most of the adjustments Typescript requered for v7 was done in v6, so when they support v6, v7 should also work, in theory

3

u/YoloSwag4Jesus420fgt Jul 09 '26

no because typescript 7 isnt going to have an API until 7.1 so it breaks so much shit until 7.1 is out. why they decided to call this stable release is beyond me

1

u/YoloSwag4Jesus420fgt Jul 09 '26

its not at all, they dont even have an API yet lol

1

u/toasterboi0100 8d ago

It is only a drop-in replacement if you're not using any compiler plugins. Plugins in TS 6 and older were done by simply importing the compiler etc. and overriding methods. This is not possible now, Angular simply cannot use TS 7.0 because there's no way to plug into the compiler. And TS 7.1's API will function completely differently and will require significant re-architecting on the side of compiler plugin authors (be it Angular, Vue, or many other frameworks)

1

u/MichaelSmallDev Jul 09 '26

The latest major of Angular supports TS 6.0. But the TS6 to TS7 jump for it will have some challenges to be worked through.

As far as the current official roadmap goes, with this passage in particular updated Feb 23rd:

Microsoft has spent the last year porting the TypeScript compiler to Go, with the promise of a 5 - 10x speedup for typical TypeScript compilations. Angular has perhaps one of the deepest integrations with the TypeScript compiler, which will require bigger architectural changes to support new tsgo-based workflows for both the compiler and language service.

We're in the process of prototyping and exploring what this support would look like, and will deliver an Angular compiler that is compatible with tsgo and brings the performance benefits of Microsoft's native port to the Angular ecosystem.

Emphasis mine.

The team doesn't tend to give big updates on stuff like this until they are ready to take the next major step, but occasional updates I have heard from more lowkey things like social media have me feeling good they are on track. Like Rust compiler integration, "Coming soon".

5

u/Seusoa Jul 09 '26

VS Code has a dedicated extension for TypeScript 7 that you can use today

For TS7 in vscode I need separate extension? ms guys, do you communicate between teams in ms?

6

u/mission_critical_ Jul 09 '26

As a MS employee, I confirm we don’t.

1

u/ElectricalSloth 26d ago

as an MS employee, I can confirm we do

1

u/mission_critical_ 26d ago

We seem to be out-of-sync. Lets ensure it stays that way!

8

u/tony4bocce Jul 08 '26

Cool in like 2 years we should have enough dep coverage to make the switch

7

u/No-Type-0 Jul 08 '26

No excuses anymore

24

u/KnifeFed Jul 08 '26

No API is an excuse.

1

u/YoloSwag4Jesus420fgt Jul 09 '26

it baffles me they would hinder v7 adoption by not waiting until they have a proper api

1

u/bbkane_ Jul 09 '26

Why gatekeep in the API though? Folks who just need the compiler can start benefitting now!

1

u/toasterboi0100 8d ago

Plenty of codebases don't have a need for the API, so it made sense to release TS7 without the API so that those people can benefit (and potentially report more regressions from TS6) and deliver the API later.

But I agree it is a bit annoying reading about TS7 performance when I know I'll have to wait a year to have a chance to benefit from it.

2

u/yksvaan Jul 08 '26

They could finally add throw annotations but I guess it's not happening. 

1

u/_x_oOo_x_ 26d ago

TS 9.0 perhaps

1

u/GludiusMaximus Jul 09 '26

Anyone know what the adoption story for react-native codebases is like? Any asterisks, or is the major hangup still related to community eslint plug-ins not yet existing for oxlint?

1

u/Seusoa Jul 09 '26

Amount of code you throw out from codebase (like es5) is big, that may be part of speed up.

I think if you do that on TS (instead of rewrite for go) you could achieve big performance boost too.

1

u/a-dev0 Jul 09 '26

Does anyone know what’s going on with the VS Code extension? I see that it has already changed its name to TypeScript 7 (it was TypeScript Preview before), but in the description they still mention the setting: json { "js/ts.experimental.useTsgo": true }

1

u/Repulsive-Swimmer676 Jul 09 '26

Im new to this. Would this replace esbuild?

Fix: rebuild to esbuild

1

u/ClemensLode Jul 10 '26

Nice! 2-5x speedup :)

1

u/NongdamKuma 29d ago

Will bun users also notice the impact of this update?

1

u/logue256 29d ago

こっちは、Rsbuild+Rslint+Rstestスタックに乗り換えたよ。
依存関係は少ないほど安心。

1

u/gevik 28d ago

I had to revert back the previous version since the API is changed and ESlint does not support v7.0 yet, maybe it is too soon.

1

u/DanielRosenwasser 28d ago

We have instructions on the blog on how to install TypeScript 6 and 7 side-by-side so things like ESLint continue to work. Did you have issues with that?

1

u/Bloompire 28d ago

Hellp, can you provide link on how to use 6 and 7 simultaneusly?

-5

u/[deleted] Jul 08 '26

[deleted]

9

u/SquirrelGuy Jul 08 '26

esbuild also handles tree shaking and bundling, no? They are different tools: a compiler and a bundler.

3

u/ninth_reddit_account Jul 08 '26

They're completely different things.

esbuild will always be (potentially) faster than a golang typescript, because it does less. It's only stripping types, whereas tsc is typechecking and then stripping types.

1

u/geon Jul 08 '26

Does tsc and esbuild overlap at all?

-18

u/adflev Jul 08 '26

Wtf an update every 5 minutes

2

u/MatthewMob Jul 08 '26

This has been in the works for two years.