-
Notifications
You must be signed in to change notification settings - Fork 12.8k
feat(#48863): Split ES5 lib into individual parts #49853
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
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
Some backstory and a lesson learned whilst implementing these changes... I originally tried to exclude the new |
@typescript-bot perf test this (though I'm not sure how well the perf tests measure startup time) |
Heya @sandersn, I've started to run the perf test suite on this PR at 0cbbb34. You can monitor the build here. Update: The results are in! |
I feel like this is something we need to discuss in a design meeting before reviewing since the code change is fairly simple but also hugely susceptible to going stale. Let's see what performance is like and then I'd vote to close the PR until the design is finalised. |
@sandersn Here they are:
CompilerComparison Report - main..49853
System
Hosts
Scenarios
TSServerComparison Report - main..49853
System
Hosts
Scenarios
Developer Information: |
@sandersn thanks for the update, I made a comment in my initial issue outlining a liking better solution to the functionality I'm looking for, but I still think that splitting up the ES5 library will be hugely beneficial to the end goal! |
No significant performance difference that I noticed. |
To help with PR housekeeping, I'm going to close this until its bug is ready. |
For future reference, what could I have done differently to get this one pushed through @sandersn? I understand that a lot of files were changed, and reviewing this would have taken some time, but the overall impact was very low, almost negligible. I'm still keen to champion this improvement if you're accepting contributions from outside collaborators 👍 |
That's a tricky one. The state Awaiting More Feedback on the issue tracker means that we're waiting for more people to chime in with reasons why they want this feature. Sometimes that's to know whether more than one person wants it, sometimes that's to find out the variety of things that could be done, and to decide which should be done. We get so many bugs and PRs that we generally don't review any outside PR until there's an accepted bug for it. Finally, for this particular feature: changing the lib, even in obviously non-breaking ways, somehow ends up breaking people. So merging this PR would make us commit to finding and fixing breaks in important libraries before the next release. |
This PR hopes to address #48863, the scale of the changes is small, and non breaking, but the impact on the tests is pretty huge. More context can be found in the linked issue explaining the changes in more depth.