microsoft
Closing TS 6.0 LS issues
Acknowledgement
- [x] 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!
Maybe at least based on issue BUGs create unit tests to be sure that functionality is working?
@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.
@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.
Since the new LSP is not a port but a re-write, I think it's valid to drop old issues.
@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.
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. 😄
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.
Perhaps the issue templates should also be changed to call out that new issues of this nature should not be filed in this repository.
Maybe at least based on issue BUGs create unit tests to be sure that functionality is working?
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.
As a TS user, I think it’s better that TD team uses their limited resource
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.