-
-
Notifications
You must be signed in to change notification settings - Fork 246
Description
This issue describes a deadlock/race condition in the lifecycle management of Corepack on Windows...\n\n### Scenario\n1. Project has a package.json with a preinstall script that invokes the package manager (e.g., pnpm dlx only-allow pnpm).\n2. User runs corepack use pnpm@latest.\n3. Corepack updates the manifest and initiates an internal install.\n4. The preinstall script is triggered. Because Corepack is currently re-linking or locking the global shims (e.g. pnpm.exe) to the new version, the child process spawned to run the script cannot find pnpm in the PATH or hits a file lock.\n5. The installation crashes, leaving the global shims in a broken state.\n\n### Related Information\n- This is exacerbated by #774, as selecting a prerelease with different binary paths immediately breaks the shim for subsequent lookups.\n\n### Proposed Fix\nI have submitted a PR (#798) that addresses this by:\n1. Preferring stable versions in
esolveDescriptor if no prerelease is explicitly requested.\n2. Setting COREPACK_PACKAGE_MANAGER_LOCATOR in
unVersion. Shims and sub-invocations can use this environment variable to bipass version lookups and use the currently active version directly, avoiding the PATH/shim race condition.