Skip to content

corepack use fails when preinstall scripts invoke the package manager #799

@AMDphreak

Description

@AMDphreak

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions