Repository navigation
Corepack hardcodes pnpm binary path instead of reading package.json bin field (breaks with pnpm v11) #775
Description
Activity
#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 usepackage.jsonmore without compromising security, that would certainly be welcome.Reacted by Tevfik Kesici, 145a, Kevin Deng and StevenIs this still reproducible with the latest
pnpm@11release candidate? If yes, what are the exact repro steps?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 v12For pnpm v12-alpha, I opened a new issue #873
Edit: This was resolved by pnpm in 12.0.0Heads 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 v12pnpm 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.- added a commit that references this issue
on Aug 5, 2026 - added a commit that references this issue
on Aug 13, 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 throughnode's bundled corepack (0.34.0, shipped
with 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 fails
identically for any pnpm ≥11.0.0, including current 12.4.1:node:internal/modules/cjs/loader:1386 throw err; ^ Error: Cannot find module '/home/.../corepack/v1/pnpm/12.4.1/bin/pnpm.cjs' at Function._resolveFilename (node:internal/modules/cjs/loader:1383:15) ... Node.js v22.21.1A separately-installed corepack 0.36.0 on the same machine resolves the
same request correctly (">=11.0.0" → "bin/pnpm.mjs"), confirming the
fix 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.jsMODULE_NOT_FOUNDstack trace with
no 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.json
dynamically" redesign ever happens:- When a requested version doesn't match any range in the embedded
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. - Consider whether corepack should compare its own bundled table's
freshness againstDate.now()(or ship a "last known good" pnpm/yarn
version 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.
- When a requested version doesn't match any range in the embedded
the problem is purely that Node bundles corepack at a cadence far slower than corepack's own releases,
-
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
-
- added a commit that references this issue
on Sep 28, 2026
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