The 4.9 iteration plan is over at #50457.

It's so sad that adding proper type support for throw is not on the roadmap for v5...

One idea I had previously floated to @amcasey was to add compiler/server APIs with asynchronous signatures in 5.0 (even if they're still synchronous under the hood), and deprecate the synchronous APIs. This would allow Typescript to later (6.0?) remove the synchronous APIs and unblock the ability to perform asynchronous I/O (or even worker-based parallelization?) in future versions.

I’d love to see the core team engage with issues that are for example 400+ thumbs up and marked “awaiting feedback” rather than issues that seem less important.
Even if the answer is that the team consider it to not be typescript’s responsibility and close the issue - i would rather that than limbo and newer but less important features being tackled.

https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3A%22Awaiting+More+Feedback%22

@lukeapage I smell another 400+ thumbs up incoming..

I’d love to see the core team engage with issues that are for example 400+ thumbs up and marked “awaiting feedback” rather than issues that seem less important. Even if the answer is that the team consider it to not be typescript’s responsibility and close the issue - i would rather that than limbo and newer but less important features being tackled.

https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3A%22Awaiting+More+Feedback%22

Waiting for any news on LSP implementation

Any plan to add experimental support ECMAScript Operator Overloading, Pipeline Operator or extension methods?

@mindlid It would be highly inappropriate to add support for any proposal prior to stage 3.

Dear TS team, i really appreciate and respect your excellent work, but so much people are waiting for the throws statement, why isn't it in the 5.0 roadmap? FMPOV this functionality is directly related to the purpose of the existence of the TypeScript – typed JS. This is the feature i really miss more then any other feature – it lacks type-safety a lot.
Would be very grateful if some of team members could give a reply about it

My bad, I was actually think about this syntax:

module Foo { }

which still works without any flag but is deprecated in favor of namespaces. Thanks for pointing it out for others who may not know about it. This is a good example of deprecation done right by TypeScript. (it would benefit from triggering a warning which does not seem to be the case with TS 4.9.x)

module Foo { isn't deprecated either (yet). See #51825.

I think a nice thing about the deprecation strategy we're using for 5.0 is that none of the guessing that's happening here is actually necessary. No Error = Not Deprecated.

Yes, but just remember that this whole discussion was about TypeScript not following SemVer and instead using an arbitrary versioning that uses the SemVer format but not the logic. If you don't want to use SemVer, it would be preferable to simply use raw version numbers like some other software do such as TS 5, TS 6... TS 123.
Then, I pointed out that your link listed deprecations, which do not constitute a breaking change under the SemVer logic and should instead be listed within a minor version. You insisted that these were breaking changes and they are not. Overall, deprecations should not break existing code, otherwise they are not deprecations, they are simply feature suppression with possibly a compatibility bridge that needs manual activation.

It seems like maybe you're not fully aware of how these deprecations are being rolled out? If you currently are targeting ES3 and try to use TS5, you will get an error you didn't get before. That's exactly the situation (my build was passing and now it's not) that 95% of "This should have been a semver major bump" complaints are about. The ease of getting back to zero errors is, in all cases, wholly irrelevant.

@typescript-bot bump release-5.0

Heya @DanielRosenwasser, I've started to update the version number on release-5.0 to 5.0.2 for you. Here's the link to my best guess at the log.

It seems like maybe you're not fully aware of how these deprecations are being rolled out? If you currently are targeting ES3 and try to use TS5, you will get an error you didn't get before. That's exactly the situation (my build was passing and now it's not) that 95% of "This should have been a semver major bump" complaints are about. The ease of getting back to zero errors is, in all cases, wholly irrelevant.

Again, deprecations should not break existing code. That is the whole concept of a deprecation. If they are breaking existing code, they are not deprecations, they are feature removal with a retro-compatibility bridge. If they are handled that way, then sure, those are breaking changes that constitute a major version. They should however be listed as such and not as deprecations.

We're having an issue with a build pipeline, so we'll be targeting the stable release for Thursday, March 16th.

Ugh, that is a typo in the release plans. 5.0.2 is the release I'm talking about. I've fixed up the original comment.

It's crazy that people have the nerve to come in here and complain. TS is literally free for us to use and everyone on the team puts a massive amount of effort into it. You should just be grateful it exists.

It's the 16th... any chance of TS5 today?

Yes! https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/

@polkovnikov-ph https://civet.dev/ supports ES proposals and compiles to typescript

@typescript-bot bump release-5.0

Heya @DanielRosenwasser, I've started to update the version number on release-5.0 to 5.0.3 for you. Here's the link to my best guess at the log.

@typescript-bot bump release-5.0

Heya @DanielRosenwasser, I've started to update the version number on release-5.0 to 5.0.4 for you. Here's the link to my best guess at the log.