Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript 5.5 Iteration Plan #57475

Closed
DanielRosenwasser opened this issue Feb 22, 2024 · 68 comments
Closed

TypeScript 5.5 Iteration Plan #57475

DanielRosenwasser opened this issue Feb 22, 2024 · 68 comments
Labels
Planning Iteration plans and roadmapping

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Feb 22, 2024

This document outlines our focused tasks for TypeScript 5.5. It minimally indicates intent to investigate tasks or contribute to an implementation. Nothing is set in stone, but we will strive to complete these tasks in a reasonable timeframe.

Date Event
2024-03-05 TypeScript 5.4 Release
2024-04-19 Create 5.5 Beta (5.5.0) Build for Testing
2024-04-24 TypeScript 5.5 Beta Release
2024-05-31 Create 5.5 RC (5.5.1) Build for Testing
2024-06-04 TypeScript 5.5 RC Release
2024-06-14 Create 5.5 Final (5.5.2) Build for Testing
2024-06-18 TypeScript 5.5 Final Release 🚀
gantt
    dateFormat  YYYY-MM-DD
    TypeScript 5.4 Stabilization Period : 2024-02-16, 2024-03-05
    TypeScript 5.5 Beta Development : 2024-02-16, 2024-04-19
    TypeScript 5.5 RC Development : 2024-04-20, 2024-05-31
    TypeScript 5.5 Stabilization Period : 2024-06-01, 2024-06-18
todayMarker stroke-width:5px,stroke:#0f0,opacity:0.5
Loading

Compiler and Language

Editor and Language Service

Performance

Website and Docs

Infrastructure

  • Adopt --isolatedDeclarations and Parallelize TypeScript's Build
@DanielRosenwasser DanielRosenwasser added the Planning Iteration plans and roadmapping label Feb 22, 2024
@DanielRosenwasser DanielRosenwasser pinned this issue Feb 22, 2024
@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Feb 22, 2024

@kevinbarabash
Copy link

How much of an impact will --isolatedDeclarations have on type checking performance in large projects?

@jakebailey
Copy link
Member

None directly, in the same way that isolatedModules doesn't speed things up in and of itself.

But, if you have code which passes isolatedModules, it can be safely transpiled by an external tool (like Babel, esbuild, swc). And similarly, code passing isolatedDeclarations can be transpiled into a declaration file by an external tool too (once one exists).

@jakebailey
Copy link
Member

(This isn't to say that there can't be some speedups possible in TypeScript in the future enabled by this option, just that the flag itself is intended to just be checks.)

@JVKdouk
Copy link

JVKdouk commented Mar 1, 2024

Hey everyone, any chance of getting #26242 in this release? It was proposed back in 2018 and there has not been much work on the issue up to this point. Getting it at least planned would already be amazing to the TS community. I believe it would substantially improve the power of TS in the long run!

@clearfram3
Copy link

Just a heads up, I'm working on remaking the website using Sveltekit. Styles will be the same, but the overall structure will be simpler and much quicker to iterate on.

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Mar 1, 2024

@ClearedFram3 while I don't want to discourage experimentation, I don't think we would accept such a large PR without discussing changes ahead of time.

@clearfram3
Copy link

@DanielRosenwasser I should've said the codebase structure will be different—the website style/content structure will be the same. After the current codebase is replaced, there will ample room for discussion about changing design and content or even to a different framework haha.

@graphemecluster
Copy link
Contributor

graphemecluster commented Mar 7, 2024

I’ve been watching the iteration plan threads from 5.4 seeing my PR (#55600) on the list. I am on standby anytime for any necessary alternations.

@jwalkerinterpres
Copy link

jwalkerinterpres commented Mar 7, 2024

Is there anything Typescript community members can do to influence this list?

I think I can speak for every TS React dev on the planet when I say that #29526 (improved syntax for destructuring an argument ... like the React props argument) has languished long enough. The community has essentially reached a consensus on a desired syntax in that ticket (something that was not easy), and now all that's needed is developer will to implement.

I can't speak for anyone else, but personally I would trade everything on the 5.5 list for this one feature!

@aspirisen
Copy link

A question about Investigate Recursive Object Type References
Will it help i.e. in zustand in avoiding writing interface for the state, and instead just infer the type from the initial state (create-function argument)?

@jcalz
Copy link
Contributor

jcalz commented Mar 20, 2024

@narcis-ro
Copy link

Is there any chance after 10 years.. to introduce nameof?

Is it super complicated? Honest question

#1579

@DanielRosenwasser
Copy link
Member Author

@typescript-bot bump release-5.4

@typescript-bot
Copy link
Collaborator

typescript-bot commented Apr 2, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
bump release-5.4 ✅ Started ✅ Results

@typescript-bot
Copy link
Collaborator

Hey, @DanielRosenwasser! I've set the version of release-5.4 to 5.4.4 for you.

@DanielRosenwasser
Copy link
Member Author

@typescript-bot bump release-5.4

@typescript-bot
Copy link
Collaborator

typescript-bot commented Apr 9, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
bump release-5.4 ✅ Started ✅ Results

@DanielRosenwasser
Copy link
Member Author

Whoops - I've been posting in the wrong iteration plan. Sorry for the noise folks.

@typescript-bot
Copy link
Collaborator

Hey, @DanielRosenwasser! I've set the version of release-5.4 to 5.4.5 for you.

@nyngwang

This comment was marked as off-topic.

@WORMSS
Copy link

WORMSS commented Apr 11, 2024

I think I can speak for every TS React dev on the planet when I say that #29526 (improved syntax for destructuring an argument ... like the React props argument) has languished long enough.

I can't disagree more with all existing proposals in #29526. It will make TypeScript syntax very confusing.

This is the first I am hearing about this.. (I guess I've had my head in the sand for a while).. We already have a solution to this.. ({ a, b }: SomeType) => void.. This makes sense, and already works..
This sounds like a massive problem waiting to happen if this gets implemented the way people are saying.

This type of stuff is going to push the whole "Javascript can run TS script directly, but just ignoring the types" concept even FURTHER AWAY!
It seems like shooting yourself in the foot to try and solve something that is already solved.

@snarbies
Copy link

But it's important to consider different voices.

Then why not add your voice to that issue? Respond to the arguments and examples presented there, there.

This type of stuff is going to push the whole "Javascript can run TS script directly, but just ignoring the types" concept even FURTHER AWAY!

Again, if you join the actual discussion you can respond to people who are addressing this exact concern (#29526 (comment)). The only argument I see in that issue is that the double-colon syntax may actually benefit this cause. If there's an argument to the contrary, you should make it there so it can be properly considered.

@jwalkerinterpres
Copy link

We already have a solution to this.. ({ a, b }: SomeType) => void

Most devs believe in the "DRY principle". When you use the syntax you mentioned, it's not DRY code; you have ({ a, b }: {a: someType; b:someType) => void (where a and b are needlessly repeated).

#29526 is simply about eliminating duplication, nothing more. There are already 30+ devs participating in that discussion (and who knows how many are lurking), all because they want to see that duplication eliminated.

If you have something against eliminated duplication, by all means respond ... in that ticket. This thread is not the appropriate place to discuss any particular ticket.

@AlttiRi
Copy link

AlttiRi commented Jun 6, 2024

2024-06-04 TypeScript 5.5 RC Release

There will no 5.5.1-rc on NPM?
https://www.npmjs.com/package/typescript?activeTab=versions

Only 5.5.0-beta until 5.5.2 is released?

@DanielRosenwasser
Copy link
Member Author

Hey all, my apologies on the delays - that's mostly on me, but as always, I'll note that the schedule is aspirational and not a promise on exact dates.

5.5.1-rc is now on npm - the blog post and the tagged release will be out on GitHub soon. Thanks for your patience!

@DanielRosenwasser
Copy link
Member Author

The blog post is out for the RC, as is the git tag v5.5-rc (and GitHub release).

@DanielRosenwasser
Copy link
Member Author

The RC got pushed back 2 days (June 6th) (typical) so the stable release will go out 2 days later (June 20th) (typical).

@DanielRosenwasser
Copy link
Member Author

@typescript-bot bump release-5.5

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 18, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
bump release-5.5 ✅ Started ✅ Results

@typescript-bot
Copy link
Collaborator

Hey, @DanielRosenwasser! I've set the version of release-5.5 to 5.5.2 for you.

@Anonymous4078
Copy link

Property 'once' does not exist on type 'EventEmitter'. Did you mean to access the static member 'EventEmitter.once' instead?

I am get this error after update to 5.5.2? My code has not change. How fix?

@Anonymous4078
Copy link

Pls fix

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Jun 20, 2024

@Anonymous4078 if you are having problems and you believe you're hitting a bug, please file a separate issue. Otherwise, if you just have an upgrade question, try asking on StackOverflow or on our Discord chat.

@HolgerJeromin
Copy link
Contributor

HolgerJeromin commented Jun 25, 2024

Was 5.5.2 withdrawn?
I can not find it on nuget.org anymore and it crashes IntelliSense in my VS2022 Version 17.10.3 (on 4 machines)

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Jun 25, 2024

@HolgerJeromin yes, there was an issue with the NuGet package due to changes in the internal layout for TypeScript. @joj and others are investigating that.

@kronodeus
Copy link

@DanielRosenwasser What is the status of the LSP support in this release? I see it in the iteration plan to "define an initial sketch" but there's nothing about it in the release notes. Are we any closer to getting it?

@jakebailey
Copy link
Member

jakebailey commented Jun 25, 2024

These iteration plans are only a prospective list; in this case I had other critical work that preempted me working on anything tangible for LSP.

What use case do you have where LSP would be valuable?

@kronodeus
Copy link

kronodeus commented Jun 25, 2024

@jakebailey We met with Daniel a few months ago to discuss our project. It's a TypeScript-based DSL with a custom file extension for which we need to implement our own VS Code extension. Our DSL is a subset of TypeScript so we need to disallow certain things and provide custom completions, etc. We implemented some of this as a tsserver plugin, but we don't want our customers to have tsconfig.json files in their projects. We don't intend to provide any of the same configuration options you get with a tsconfig.json. We have our own config file. We want them to simply install the VS Code extension and for everything to work.

It is possible to load a tsserver plugin inside a VS Code extension without requiring the user to have a tsconfig.json, but since there is only one instance of tsserver running at a time in VS Code, this plugin would then be active for all of the user's TypeScript files unless they disable the extension.

Our options are thus: (A) Fork the internal typescript-language-features extension, (B) implement an extension from scratch using a community-developed LSP wrapper like vtsls, or (C) implement an extension from scratch using tsserver directly with our own LSP adapter layer.

@jakebailey
Copy link
Member

jakebailey commented Jun 25, 2024

I don't really see how LSP would help that situation; LSP will within reason only change the way tsserver talks to the editor. It'd still be the same ProjectService under the hood, with the same gotchas. What you're describing sounds more suited to plugging into something like volar, the system that vue, mdx, etc, use to slap their custom languages on top of TS. (Not that I have any experience with it, or that it's supported by TS in any way.)

In any case, I think this is the wrong place to discuss it (pinging everyone interested in the 5.5 release process); the update is just that "I didn't have time to work on it". The current LSP thinking is to slowly onboard calls away from the old protocol onto the new one, so it's not going to be like one day we aren't LSP and one day we are, either.

@DanielRosenwasser
Copy link
Member Author

@typescript-bot bump release-5.5 and LKG

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 26, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
bump release-5.5 and LKG ✅ Started ✅ Results

@typescript-bot
Copy link
Collaborator

Hey, @DanielRosenwasser! I've set the version of release-5.5 to 5.5.3 for you.

@DanielRosenwasser
Copy link
Member Author

5.5.3 is out with the NuGet/VS issues fixed. Thanks for your patience everyone!

@MunMunMiao
Copy link

Will #26242 be implemented in the next version, as it is so important to library developers?

@DanielRosenwasser
Copy link
Member Author

@typescript-bot bump release-5.5 and LKG

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jul 22, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
bump release-5.5 and LKG ✅ Started ✅ Results

@typescript-bot
Copy link
Collaborator

Hey, @DanielRosenwasser! I've set the version of release-5.5 to 5.5.4 for you.

bludnic added a commit to bludnic/opentrader that referenced this issue Jul 25, 2024
@RyanCavanaugh RyanCavanaugh unpinned this issue Sep 9, 2024
@yuhuung
Copy link

yuhuung commented Sep 10, 2024

Is there any reference link for Improved Performance for Git Branch Switching Scenarios? @DanielRosenwasser Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Planning Iteration plans and roadmapping
Projects
None yet
Development

No branches or pull requests