npm "overrides" vs Yarn "resolutions" - Fix Pin Ignored After Switching Managers

npm pins transitive versions with a top-level overrides block; Yarn (and historically others) use resolutions. They are not interchangeable - npm ignores resolutions, and Yarn classic ignores overrides - so switching managers (or copying a config) silently drops the pin.

What this error means

A transitive dependency you pinned still installs at the wrong version in CI after switching from Yarn to npm (or vice versa). The pin lives in the field the current package manager does not read, so it is ignored without error.

package.json / npm output

// package.json - Yarn-style pin, but CI now runs npm:
"resolutions": { "semver": "7.5.4" }

# npm ignores "resolutions"; it still resolves the old version:
$ npm ls semver
└─┬ some-dep@2.0.0
  └── semver@6.3.0

Common causes

Pin written in the other manager’s field

npm honors overrides; Yarn classic honors resolutions. A config carried over from the other tool puts the pin in a field the active manager ignores.

Lockfile not regenerated after the switch

Even with the right field, the pin only applies once the active manager regenerates its lockfile to encode it.

How to fix it

Use the field your manager reads

Put the pin in overrides for npm or resolutions for Yarn, then regenerate that manager’s lockfile.

package.json / Terminal

// for npm
"overrides": { "semver": "7.5.4" }

// for Yarn
"resolutions": { "semver": "7.5.4" }

# then regenerate the active manager's lockfile and verify
npm install && npm ls semver

Verify the pin took effect

After installing, run npm ls <pkg> (or yarn why <pkg>) to confirm the resolved version.
Ensure the corresponding lockfile is regenerated and committed.
Pin the package manager via packageManager so the team uses one tool.

How to prevent it

Pin transitive versions in the field your manager reads.
Regenerate and commit the matching lockfile after changes.
Standardize on one package manager via packageManager.