Repository navigation
Closing TS 6.0 LS issues #62827
Description
Acknowledgement
- I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.
Comment
As discussed in our December blog post, we're in the process of closing all bugs related to the JavaScript implementation (AKA Strada AKA TypeScript versions 1.1 through 6.0) of the language service.
Why?
A very large part of the language service has basically been rewritten from scratch:
- We now use LSP instead of a custom protocol
- A large amount of logic was not directly portable, so got hand-authored instead, thus likely has a different set of problems
It's extremely time-consuming (and low-yield) to try to verify these issues, so instead we're taking a more blunt approach and instead doing a one-time bulk close of these issues.
In a future step, we'll also be applying this to PRs that change language service behavior, as all future development efforts should be invested in the native codebase. It's important that 6.0 remain a stable release and merging these PRs would potentially introduce servicing costs that would be better spent on the 7.0 codebase.
Why not tsc bugs too?
The port of the core checker logic is extremely faithful to the existing codebase, so almost every checking bug in TS is still present in the Go version (for better or worse!). We're trying to apply some more aggressive auto-verification of old bugs just to keep things tidy, but auto-closing checker bugs right now would discard too many valid issues.
When?
Now-ish, subject to GitHub API rate limits 🙂
What (should you do about it)?
Please try out your scenario in the TypeScript Native Nightly extension.
Three cases to consider:
- The feature isn't implemented yet, wait and try again later
- If the bug is fixed, no action is needed
- If the bug is still present, please log a new issue in the native repo so we can investigate
Happy coding!
Activity
psnet commentedon Dec 3, 2025
Maybe at least based on issue BUGs create unit tests to be sure that functionality is working?
vitonsky commentedon Dec 3, 2025
Ryan Cavanaugh (@RyanCavanaugh) this approach devalues community efforts and make me think a TypeScript is not really open source, since you just ignore the voice of community.
You don't even add a tests based on user reports and your justification is "we are lazy" and "it's time-consuming".
I think such behaviour in result will make part of people don't want to report a new bugs and TypeScript quality will degrade even more.
mkantor commentedon Dec 3, 2025
Robert Vitonsky (@vitonsky) Being fair, the justification is that "it's extremely time-consuming (and low-yield)", and I believe that. I'd rather the TypeScript team spend a few person-weeks (completely made up but I suspect around the right order of magnitude) pushing 7.0 towards the finish line rather than on verification/reproduction of old/mostly-stale issues. Crowd-sourcing that work seems smart to me.
If there's a particular bug you need help verifying, I'd be happy to assist.
itsUndefined commentedon Dec 3, 2025
Since the new LSP is not a port but a re-write, I think it's valid to drop old issues.
vitonsky commentedon Dec 3, 2025
Themistoklis Chatziemmanouil (@itsUndefined) should we erase all memories when go to a new Job or become relationships with a new partner? Just because we can don't care anymore about a challenges we seen previously.
It does not quite make sense. Because knowledge and experience we've got before, make us stronger now, and allow to solve similar problems easily, because we know well how it does.
The same with a software development. In case we drop exists issues - we just throw into the fire the knowledge that could help us to build safety net and avoid the same bugs over and over.
mkantor commentedon Dec 3, 2025
The issues haven't been "erased", just closed. They're still publicly-visible, and this issue is encouraging people to re-file them in the new repository if they are reproducible.
I've mostly "closed" my issues with my exes too. 😄
rubiesonthesky commentedon Dec 3, 2025
It’s only about the Language Server. Not type checking or compiling (as far as I understood). There are 500 issues closed now that can be easily find with the added label. Most of them seem to be hard to reproduce or test. They probably don’t affect that many users or they are really minor inconveniences.
As a TS user, I think it’s better that TD team uses their limited resources to the more pressing issues and finishing the go port. It’s been stated before that they don’t have a lot resources and I think they lost recently devs when Microsoft laid off a lot people.
Most projects need to do some scoping and prioritise their work. There are still almost 5000 open issues and I don’t think they all will ever be resolved.
mkantor commentedon Dec 3, 2025
Perhaps the issue templates should also be changed to call out that new issues of this nature should not be filed in this repository.
RyanCavanaugh commentedon Dec 3, 2025
This would at best be a manual process, since the issues themselves aren't testcases. I tried to use AI to distill these issues into tests, but it failed pretty badly. Our best use of time isn't manually converting 500 issues into testcases.
It's fundamentally this. If anyone's best use of time is to go through these ~500 issues and see if they still repro in 7.0, they're free to do so (and one of many reasons I made the label - so you can see exactly which issues were affected) - but it's not our best use of time. Same goes if anyone feels like converting these issues to tests.
magic-akari commentedon Dec 24, 2025
Hi team,
Would it be possible to exclude issues that have an associated open PR from this bulk closure?
For example, #42468 has a fix in #62818 that's currently under review. It would be great to keep those issues open so they can be resolved through the normal PR process and properly attributed.
This might also help avoid closing issues that are actually in progress of being fixed.
Thanks for all the work on TS 7.0!
coderrshyam commentedon Dec 26, 2025
MicrosoftownsGithub, you can make request to team leader ofGithub API. 😅😅Bashamega commentedon Dec 26, 2025
Different teams Shyam Verma (@coderrshyam), different offices
RyanCavanaugh commentedon Jan 5, 2026
magic-akari we are very unlikely to merge those PRs, since we're trying to minimize code churn in 6.0