Closed das7pad closed 2 months ago
corepack tries to discover the latest version to prepare a
fallbackLocator
inEngine.executePackageManagerRequest
first, but without alastKnownGood.json
(corepack install
does not prepare it), it attempts a network request
I wonder if https://github.com/nodejs/corepack/pull/432/files#diff-ac2e60980d41d74acab8d4ec9d41b6bd52b08f056b3ea65f89952de64eca3601 did not fix that already.
Description
Closes https://github.com/nodejs/corepack/issues/183 Closes https://github.com/nodejs/corepack/issues/422
This PR is separating read and write operations on
lastKnownGood.json
. It will also skip overwritinglastKnownGood.json
with 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.json
is validated/sanitized when reading. Any consumers can operate on theRecord<string, string>
object directly. This greatly simplified the logic inactivatePackageManager
andgetLastKnownGoodFromFileContent
.I could not get the "per-project" install to work fully offline/read-only in a straightforward way (just running
corepack install
). Runningcorepack install
only caches the requested binary frompackage.json -> packageManager
. When invoking the package-manager (yarn) viacorepack yarn
, corepack tries to discover the latest version to prepare afallbackLocator
inEngine.executePackageManagerRequest
first, but without alastKnownGood.json
(corepack install
does not prepare it), it attempts a network request. The "code fix" here is to defer thefallbackLocator
work until after discovering anypackage.json
file. 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 --version
once populates thelastKnownGood.json
cache.