First, thanks for the incredibly quick turnaround on #11387 — shipping the fix in 11.0.1 the same day was impressive!
Description
The fix in #11392 for syncing stale packageManagerDependencies entries works correctly, but is bypassed when pnpm is executed via corepack. Since devEngines.packageManager typically implies corepack usage, the fix is effectively unreachable for the primary use case.
Root Cause
In pnpm/src/main.ts, the package manager handling block (including syncEnvLockfile) is wrapped in:
if (!isExecutedByCorepack() && cmd !== 'setup' && ...) {
// ...
checkPackageManager(pm)
await syncEnvLockfile(config, context)
}
When corepack invokes pnpm, COREPACK_ROOT is set, causing isExecutedByCorepack() to return true and skip the entire block.
Steps to Reproduce
-
Use devEngines.packageManager in package.json:
{
"devEngines": {
"packageManager": {
"name": "pnpm",
"version": "11.0.1"
}
}
}
-
Have a stale lockfile with old version in packageManagerDependencies:
packageManagerDependencies:
pnpm:
specifier: 11.0.0-rc.5
version: 11.0.0-rc.5
-
Run pnpm install (which goes through corepack due to devEngines)
-
Observe that packageManagerDependencies remains at rc.5 despite running pnpm 11.0.1
Expected Behavior
The packageManagerDependencies section should be updated to 11.0.1, matching the running pnpm version.
Actual Behavior
The stale rc.5 entry persists because syncEnvLockfile is never called when COREPACK_ROOT is set.
The Gap
- Corepack: Manages which pnpm version runs, but doesn't touch the lockfile
- pnpm: Has code to update the lockfile (
syncEnvLockfile), but skips it when corepack is involved
This creates a situation where neither tool updates the packageManagerDependencies section.
Suggested Fix
Consider running syncEnvLockfile even when executed by corepack, at least for the case where devEngines.packageManager is declared. The lockfile integrity record is still valuable even when corepack handles version selection.
Environment
- pnpm version: 11.0.1
- Node.js version: 24.x
- corepack version: (bundled with Node)
- OS: macOS
Related
First, thanks for the incredibly quick turnaround on #11387 — shipping the fix in 11.0.1 the same day was impressive!
Description
The fix in #11392 for syncing stale
packageManagerDependenciesentries works correctly, but is bypassed when pnpm is executed via corepack. SincedevEngines.packageManagertypically implies corepack usage, the fix is effectively unreachable for the primary use case.Root Cause
In
pnpm/src/main.ts, the package manager handling block (includingsyncEnvLockfile) is wrapped in:When corepack invokes pnpm,
COREPACK_ROOTis set, causingisExecutedByCorepack()to returntrueand skip the entire block.Steps to Reproduce
Use
devEngines.packageManagerin package.json:{ "devEngines": { "packageManager": { "name": "pnpm", "version": "11.0.1" } } }Have a stale lockfile with old version in
packageManagerDependencies:Run
pnpm install(which goes through corepack due to devEngines)Observe that
packageManagerDependenciesremains at rc.5 despite running pnpm 11.0.1Expected Behavior
The
packageManagerDependenciessection should be updated to 11.0.1, matching the running pnpm version.Actual Behavior
The stale rc.5 entry persists because
syncEnvLockfileis never called whenCOREPACK_ROOTis set.The Gap
syncEnvLockfile), but skips it when corepack is involvedThis creates a situation where neither tool updates the
packageManagerDependenciessection.Suggested Fix
Consider running
syncEnvLockfileeven when executed by corepack, at least for the case wheredevEngines.packageManageris declared. The lockfile integrity record is still valuable even when corepack handles version selection.Environment
Related
syncEnvLockfile)