Description

When devEngines.packageManager specifies a different version than what's recorded in the lockfile's packageManagerDependencies section, pnpm silently proceeds without any warning or error. This defeats the purpose of integrity verification.

Steps to Reproduce

1. Have a lockfile with:

   packageManagerDependencies:
     pnpm:
       specifier: 11.0.0-rc.5
       version: 11.0.0-rc.5

2. Set devEngines.packageManager to a different version:

   {
     "devEngines": {
       "packageManager": {
         "name": "pnpm",
         "version": "11.0.0"
       }
     }
   }

3. Run pnpm install

Expected Behavior

pnpm should either:

• Error or warn about the version mismatch between devEngines.packageManager (11.0.0) and lockfile (11.0.0-rc.5)
• Automatically update the lockfile to match the declared version

Actual Behavior

pnpm silently uses version 11.0.0 (from devEngines) without any indication that the lockfile's packageManagerDependencies is stale/mismatched. No warning, no error.

This means:

• The integrity verification in the lockfile is effectively ignored
• Users have no indication that their lockfile is out of sync
• The packageManagerDependencies section becomes misleading (shows rc.5 but 11.0.0 is actually used)

Environment

• pnpm version: 11.0.0
• Node.js version: 24.x
• OS: macOS

Related

• Related to packageManagerDependencies not updated when migrating from legacy packageManager to devEngines.packageManager #11386 (packageManagerDependencies not being updated during migration)
• The combination of these two issues means integrity verification is silently broken when migrating from legacy packageManager to devEngines.packageManager