You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some times when updating branches or doing npm ci, instead of file change event, we may get file delete followed by file create event.
This was previously handled not so efficiently as: as soon as we get delete event say on configFile for the project, we would remove the whole project from memory and schedule update for open files, only to get file create so end up creating project again.
With this change:
784e0ef When config file watched gets deleted, we defer removing/closing it and reuse if we get create event, we can just mark this project for update and remove its defer delete option. The deferred delete marked project is kept alive and acts as orphan project until next file open which is when we normally do gc on all projects and scriptInfos. Note we do something similar for inferred project so we can reuse it so its just extending that concept to configured project
bd10117 For scriptInfos that are deleted, they are also kept around and watched till next file open, so we can reuse the text and version if it doesnt change. Eg npm ci can replace file with same text and this helps with file usage. Again these deferred removed on next file open.
Other two commits in the PR are tests before the change to cover for scenarios of file delete, recreate etc and refactoring
This should also help with #57196 when we would open more projects and configs to search for your default project
Without proper repro to measure perf reliably but in my dogfooding and from tests it seems to really help with the perf in these kind of scenarios. (No guarantee when timeout happens and how things will unfold to see if delete, create happen or not)
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page.
The reason will be displayed to describe this comment to others. Learn more.
This seems fine to me (though I don't know how to physically test it), though I think my main concern are API users who expect that closing a file actually frees its resources. I'm not sure if ts-eslint actually closes any files, though.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some times when updating branches or doing
npm ci
, instead of file change event, we may get file delete followed by file create event.This was previously handled not so efficiently as: as soon as we get delete event say on configFile for the project, we would remove the whole project from memory and schedule update for open files, only to get file create so end up creating project again.
With this change:
defer delete
option. The deferred delete marked project is kept alive and acts as orphan project until next file open which is when we normally dogc
on all projects and scriptInfos. Note we do something similar for inferred project so we can reuse it so its just extending that concept to configured projectnpm ci
can replace file with same text and this helps with file usage. Again these deferred removed on next file open.Other two commits in the PR are tests before the change to cover for scenarios of file delete, recreate etc and refactoring
This should also help with #57196 when we would open more projects and configs to search for your default project
Without proper repro to measure perf reliably but in my dogfooding and from tests it seems to really help with the perf in these kind of scenarios. (No guarantee when timeout happens and how things will unfold to see if delete, create happen or not)