Separate read and write operations on lastKnownGood.json #446
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.
Description
Closes #183
Closes #422
This PR is separating read and write operations on
lastKnownGood.json. It will also skip overwritinglastKnownGood.jsonwith the same content.Review
This PR is best reviewed with white space changes ignored due to indentation changes from removing try/catch/finally blocks.
I refactored the read and write operations into self contained functions. The re-use of a
r+file handle does not work anymore when separating the two kinds of operations.The content of
lastKnownGood.jsonis validated/sanitized when reading. Any consumers can operate on theRecord<string, string>object directly. This greatly simplified the logic inactivatePackageManagerandgetLastKnownGoodFromFileContent.I could not get the "per-project" install to work fully offline/read-only in a straightforward way (just running
corepack install). Runningcorepack installonly caches the requested binary frompackage.json -> packageManager. When invoking the package-manager (yarn) viacorepack yarn, corepack tries to discover the latest version to prepare afallbackLocatorinEngine.executePackageManagerRequestfirst, but without alastKnownGood.json(corepack installdoes not prepare it), it attempts a network request. The "code fix" here is to defer thefallbackLocatorwork until after discovering anypackage.jsonfile. This is a major undertaking and something for another day. I left a note for this in a comment in the "per-project" test, next to the workaround: runningcorepack yarn --versiononce populates thelastKnownGood.jsoncache.