Daniel Rosenwasser
@danr.bsky.social
TypeScript Product Manager and TC39 rep working on JavaScript standards.
Enthusiast of compilers, dev tools, language VMs/runtimes.
Enthusiast of compilers, dev tools, language VMs/runtimes.
We're hoping for TypeScript 6.0 early 2026 (think February or earlier) and 7.0 shortly after.
We're looking for people to use the native previews of 7.0 for feedback ASAP though. We feel the language service is pretty solid these days!
We're looking for people to use the native previews of 7.0 for feedback ASAP though. We feel the language service is pretty solid these days!
November 12, 2025 at 6:20 AM
We're hoping for TypeScript 6.0 early 2026 (think February or earlier) and 7.0 shortly after.
We're looking for people to use the native previews of 7.0 for feedback ASAP though. We feel the language service is pretty solid these days!
We're looking for people to use the native previews of 7.0 for feedback ASAP though. We feel the language service is pretty solid these days!
I write it anyway, otherwise it's hard to Jakegle anything about it.
October 29, 2025 at 7:30 AM
I write it anyway, otherwise it's hard to Jakegle anything about it.
Right but which was #1? Jakelang or SavannahScript?
October 28, 2025 at 9:37 PM
Right but which was #1? Jakelang or SavannahScript?
And of course, we have the @vscode.dev extension for @typescriptlang.org native previews published nightly too!
marketplace.visualstudio.com/items?itemNa...
marketplace.visualstudio.com/items?itemNa...
TypeScript (Native Preview) - Visual Studio Marketplace
Extension for Visual Studio Code - Preview of the native TypeScript language server for Visual Studio Code.
marketplace.visualstudio.com
October 24, 2025 at 12:25 AM
And of course, we have the @vscode.dev extension for @typescriptlang.org native previews published nightly too!
marketplace.visualstudio.com/items?itemNa...
marketplace.visualstudio.com/items?itemNa...
Congratulations!! 🎉🎉
October 3, 2025 at 11:02 PM
Congratulations!! 🎉🎉
Isn't this already the behavior of strict being on? Before users had to opt in to breakiness.
The big problem is that if strict is on for everyone, we always have to think about this on the context of "now everyone is broken" which was always the reason we didn't do it.
The big problem is that if strict is on for everyone, we always have to think about this on the context of "now everyone is broken" which was always the reason we didn't do it.
August 26, 2025 at 10:20 PM
Isn't this already the behavior of strict being on? Before users had to opt in to breakiness.
The big problem is that if strict is on for everyone, we always have to think about this on the context of "now everyone is broken" which was always the reason we didn't do it.
The big problem is that if strict is on for everyone, we always have to think about this on the context of "now everyone is broken" which was always the reason we didn't do it.
I get the broader point. For specific options, I think noUncheckedIndexedAccess may be a little rough for most people, but we might be able to do better analyses with a faster TS.
With exactOptionalPropertyTypes, that requires a bit more of an ecosystem adaptation, and it's very annoyingly subtle.
With exactOptionalPropertyTypes, that requires a bit more of an ecosystem adaptation, and it's very annoyingly subtle.
August 25, 2025 at 5:24 PM
I get the broader point. For specific options, I think noUncheckedIndexedAccess may be a little rough for most people, but we might be able to do better analyses with a faster TS.
With exactOptionalPropertyTypes, that requires a bit more of an ecosystem adaptation, and it's very annoyingly subtle.
With exactOptionalPropertyTypes, that requires a bit more of an ecosystem adaptation, and it's very annoyingly subtle.
I'll bring it up in the issue though.
August 25, 2025 at 5:03 PM
I'll bring it up in the issue though.
You mean like saying that `noImplicitAny` has "graduated" to being using useful enough to turn it on by default?
I do like that, but I think being able to say "all of strict is on" is a little bit easier to think about than "most of strict is now empty and these 10 flags are now on".
I do like that, but I think being able to say "all of strict is on" is a little bit easier to think about than "most of strict is now empty and these 10 flags are now on".
August 25, 2025 at 5:03 PM
You mean like saying that `noImplicitAny` has "graduated" to being using useful enough to turn it on by default?
I do like that, but I think being able to say "all of strict is on" is a little bit easier to think about than "most of strict is now empty and these 10 flags are now on".
I do like that, but I think being able to say "all of strict is on" is a little bit easier to think about than "most of strict is now empty and these 10 flags are now on".