pnpm "packageManager" version mismatch with corepack in CI

The packageManager field pins an exact pnpm version. When corepack is active and a different pnpm tries to run, corepack refuses so builds stay reproducible across machines.

What this error means

A pnpm step fails with "This project is configured to use pnpm because of a packageManager field" or "Corepack must be enabled" when the invoked pnpm version does not match the pin.

Usage Error: This project is configured to use pnpm because of a packageManager field, but the current global installation of pnpm (10.4.0) does not match the version defined (9.15.0).

Common causes

A global pnpm differs from the pinned version

pnpm/action-setup installed a version that conflicts with the exact version in packageManager, and corepack enforces the pin.

Two provisioning methods disagree

Both corepack and a separately installed pnpm are on PATH at different versions, so the running one does not match the field.

How to fix it

Let corepack drive the pinned version

1. Set the exact version in packageManager.
2. Enable corepack and let it prepare that version.
3. Do not also pin a conflicting version in pnpm/action-setup.

{
  "packageManager": "pnpm@9.15.0"
}

Prepare the exact version explicitly

If corepack has not activated the pinned version yet, prepare and activate it before installing.

- run: corepack enable
- run: corepack prepare pnpm@9.15.0 --activate
- run: pnpm install --frozen-lockfile

How to prevent it

• Pin one exact pnpm version in packageManager and let corepack use it.
• Avoid setting a conflicting version: in pnpm/action-setup when corepack is on.
• Keep local and CI pnpm in sync via the packageManager field.

Related guides