-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Schedule failed lookup updates #38560
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
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at c80a83e. You can monitor the build here. |
@weswigham does bot not pack build that fails to run tests |
Eeeyeah, it does not; it's templated off the publish task which, for sanity reasons, makes sure tests pass prior to publication. If you wanna override those sanity checks in a PR, you can always game the system a little bit and edit the |
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at bd2f7b7. You can monitor the build here. |
Hey @sheetalkamat, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes make sense to me; it’s clear where you’re throttling an operation that was previously not throttled. The only thing that I can’t figure out is why this wasn’t a problem with npm as well as yarn.
@andrewbranch i dont understand what you mean. #37055 changed how module resolutions are updated and that means that npm/yarn install notifications were producing lot more work to check if things need to be invalidated. Before that PR we would just mark project as ready for update and schedule one which would keep on cancelling and scheduling so not much work involved in there. This PR merges both behaviours by scheduling invalidation of module resolutions so we can process them all at once instead of on every notification from FS. |
Ok, I was under the impression that this bug was unique to yarn. |
* upstream/master: (36 commits) Update baselines (microsoft#39000) Make isEntityNameVisible duplicate the node builder logic to always consider type parameters as visible if they are the resolution result (microsoft#38921) Schedule failed lookup updates (microsoft#38560) Remove non null assertion on oldSourceFile.resolvedModules (microsoft#38984) use blocklist instead of blacklist (microsoft#38988) LEGO: check in for master to temporary branch. Deprecate reloadFs so the tests are more clear in what they are achieving and its easier to track changed behaviour (microsoft#38954) LEGO: check in for master to temporary branch. LEGO: check in for master to temporary branch. Make `hasCorrectArity` handle tuples properly fix error when use spread arguments twice fix(38081): allow transforming object binding to named imports Accept baseline fix names Fix type and simplify code accept new baseline fix rebase conflict add missing semi Add more check fix mission baseline ...
Schedule invalidation of module resolution cache on changes to failed lookup locations.
Fixes #37653