Corepack "this project is configured to use yarn" in CI - Fix Package Manager Mismatch

By Daniel Zoghalchali·Latchkey

Corepack pins a package manager via the packageManager field. When you run a different manager than the one declared, Corepack refuses and tells you which one the project expects.

What this error means

A CI step running npm or pnpm errors saying this project is configured to use yarn (or a specific version), because packageManager in package.json pins a different tool than the command invoked.

yarn

Usage Error: This project is configured to use yarn because
package.json#packageManager is set to "yarn@4.1.0".
Run "corepack enable" to make the command work.

Diagnose it: reproduce the CI install locally

Install failures are usually environment drift rather than a broken lockfile: a different package-manager major, a different Node version, or a cache that is being restored from a run with different inputs. Reproduce the CI conditions before changing the lockfile, because regenerating it hides the real cause.

Terminal

# match the runner exactly, then install from a clean slate
node --version && npm --version
rm -rf node_modules
npm ci --foreground-scripts

# if that succeeds locally but fails in CI, the difference is the cache
# or the package-manager version, not your lockfile

Common causes

The job runs a manager other than the pinned one

packageManager pins yarn (or pnpm), but the CI step calls npm, so Corepack blocks it.

Corepack is not enabled in CI

Without corepack enable, the pinned manager shim is not on PATH and the command fails.

How to fix it

Enable Corepack and use the pinned manager

Run corepack enable so the pinned shims are available.
Invoke the manager named in packageManager.

Terminal

corepack enable
yarn install --immutable

Change packageManager if the project really uses npm

Update or remove the packageManager field to match your actual tool.
Commit the change so CI and local agree.

Verify the fix survives a cold cache

A green run immediately after a fix often proves nothing, because it restored a cache written before the change. Force a cold install once to confirm the fix is real.

.github/workflows/ci.yml

# temporarily bust the cache key to prove the fix on a cold runner
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: npm
    cache-dependency-path: package-lock.json
# then bump this suffix once, run, and remove it
#   key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}-v2

How to prevent it

Pick one package manager, pin it in packageManager, run corepack enable in CI, and use that same manager in every script so commands never get blocked.

Frequently asked questions

What causes Corepack "this project is configured to use yarn" in CI?

There are 2 common causes: the job runs a manager other than the pinned one and corepack is not enabled in ci. packageManager pins yarn (or pnpm), but the CI step calls npm, so Corepack blocks it.

How do I fix Corepack "this project is configured to use yarn" in CI?

There are 2 fixes depending on which cause you have: enable corepack and use the pinned manager and change packagemanager if the project really uses npm. Work through them in order, since the first is the most common.

What does Corepack "this project is configured to use yarn" in CI actually mean?