Repository navigation
Corepack hardcodes pnpm binary path instead of reading package.json bin field (breaks with pnpm v11) #775
Description
After some discussion on the pnpm issue (pnpm/pnpm#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 pnpm@10.22.0orcorepack 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 (pnpm/pnpm#10214 (comment)), 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
Activity
alexsch01 commentedon Nov 25, 2025
this can probably be closed by #776
aduh95 commentedon Nov 25, 2025
#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.jsonto get the correct executable paths is unlikely to be dangerous, but also upstream very rarely change shape that maintainingconfig.jsonhas not really been an issue.Anyway, if someone were to send a PR to make Corepack use
package.jsonmore without compromising security, that would certainly be welcome.MikeMcC399 commentedon Apr 23, 2026
Is this still reproducible with the latest
pnpm@11release candidate? If yes, what are the exact repro steps?bhuynhdev commentedon Jul 14, 2026
Heads up that: This seems to also break with pnpm v12-alpha, which has changed its bin path compared to v11, so supposedly the
config.jsonfile needs to be updated for pnpm v12MikeMcC399 commentedon Jul 15, 2026
For pnpm v12-alpha, I opened a new issue #873
Edit: This was resolved by pnpm in 12.0.0
MikeMcC399 commentedon Jul 15, 2026
@bhuynhdev
pnpm has accepted issue pnpm/pnpm#13018 as a regression in
pnpm@12.0.0-alpha.11. You can follow the progress if you subscribe to the issue in the pnpm repo.Compatibility with pnpm@11 has already been resolved in the interim. So the issue here (#775) should probably be viewed as an enhancement request to dynamically interpret the
package.jsoncontents of pnpm.Switch Railway API build from Nixpacks to a Dockerfile
feat: support pnpm v12, which is distributed as a native executable
bukzor commentedon Sep 17, 2026
Another data point for the hardcoded-table problem, from a different distribution channel
This bit me via a channel not yet mentioned on this thread: Node's own
bundled corepack, not corepack's own release cadence. My global
package-manager upgrade cron job hit an identical failure to the
original report, but through
node's bundled corepack (0.34.0, shippedwith Node 22.21.1, installed ~Dec 2025) rather than a manually-installed
corepack. Its embedded pnpm range table is
">=6.0.0" → "bin/pnpm.cjs"-- a single catch-all that predates the
.mjsmigration -- so it failsidentically for any pnpm ≥11.0.0, including current 12.4.1:
A separately-installed corepack 0.36.0 on the same machine resolves the
same request correctly (
">=11.0.0" → "bin/pnpm.mjs"), confirming thefix from #887 works -- the problem is purely that Node bundles
corepack at a cadence far slower than corepack's own releases, and
there's no floor-version check or user-facing signal when the bundled
copy predates support for the requested package-manager version. The
failure a user sees is a bare Node.js
MODULE_NOT_FOUNDstack trace withno mention of corepack, its version, or that the target package manager
is simply outside what this corepack build knows about.
Two asks, independent of whether the broader "read
package.jsondynamically" redesign ever happens:
table, fail with a corepack-authored message naming the corepack
version and suggesting an upgrade, instead of falling through to
whatever the nearest-but-wrong range produces.
freshness against
Date.now()(or ship a "last known good" pnpm/yarnversion per corepack release) so an old, Node-bundled corepack can
at least say "I predate support for pnpm 12" rather than guessing
wrong silently.
Happy to provide any further logs/versions on request.
MikeMcC399 commentedon Sep 18, 2026
Node.js does not bundle Corepack in Node.js >=25 - see README. Users choose themselves if they want to install Corepack, and which version.
Node.js 22 is the Maintenance LTS version. If you want to receive more recent updates, then use Node.js 24, the Active LTS version. Next month the Active LTS version will move to be Node.js 26.
pnpm >=11 no longer recommends Corepack- see Release corepack@1.0.0 #687 (comment) & Release corepack@1.0.0 #687 (comment)
The type of self-update you are looking for with Corepack is already available in pnpm itself - see https://pnpm.io/installation#using-pnpm
fix: pin pnpm to the 10.x line so corepack can actually load it