Corepack hardcodes pnpm binary path instead of reading package.json bin field (breaks with pnpm v11)

[tkesici]

After some discussion on the pnpm issue (https://github.com/pnpm/pnpm/issues/10214), it turns out the problem is not caused by a faulty pnpm release, pnpm v11 has changed its binary entry path from bin/pnpm.cjs to bin/pnpm.mjs., so the development build 11.0.0-dev.1005 is not faulty. Corepack is expecting the old path and fails.

So the issue appears to be:

• Corepack’s version resolution prefers a dev build over the latest stable
• Corepack seems to rely on a hardcoded pnpm binary path instead of reading the correct bin path from package.json.

As a workaround I'm currently using corepack use [email protected] or corepack use pnpm@latest (or latest-9, latest-10 etc.)

Leaving this update here so the root cause is clearer.

Originally posted by @tkesici in #772

Problem

Corepack appears to rely on a hard-coded pnpm binary path (bin/pnpm.cjs) instead of reading the bin field from pnpm’s package.json.

pnpm v11 changed its binary entry from bin/pnpm.cjs to bin/pnpm.mjs (https://github.com/pnpm/pnpm/issues/10214#issuecomment-3566728733), so when corepack installs pnpm v11, pnpm cannot start and the process fails.

Expected Behavior

Corepack should read the bin property from pnpm’s package.json to determine the correct executable path

Actual Behavior

Corepack assumes the binary always exists under bin/pnpm.cjs, which is no longer valid for pnpm v11.

Environment

Node.js: 20 (node:20-alpine)

Corepack: 0.34.4

OS: Alpine Linux

[alexsch01]

this can probably be closed by https://github.com/nodejs/corepack/pull/776

[aduh95]

https://github.com/nodejs/corepack/pull/776 does fix pnpm integration, but it doesn't really address this issue.

I think this issue is about should Corepack be more dynamic (and therefore, more susceptible to supply chain attacks), or rely on hard-coded information (and therefore, more fragile when the upstream packages change shape). I don't have a definite opinion myself, on one hand trusting package.json to get the correct executable paths is unlikely to be dangerous, but also upstream very rarely change shape that maintaining config.json has not really been an issue. Anyway, if someone were to send a PR to make Corepack use package.json more without compromising security, that would certainly be welcome.