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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions