Add a packageManager field to package.json naming yarn, npm or pnpm and an exact version, and Corepack will use that version for the project. The Corepack documentation says an integrity hash is optional but strongly recommended as a security practice. Check whether your Node.js version bundles Corepack before you rely on it.
What Corepack is
The Corepack readme describes it as a zero-runtime-dependency Node.js script that bridges Node.js projects and their package managers. It lets you use Yarn, npm and pnpm without installing them separately.
The idea is simple. Instead of each developer running whatever package manager version they happen to have, the repository declares it. Everyone gets the same resolver behavior, the same lockfile format and the same fixes.
The field
You set the package manager with the packageManager field in package.json, and the docs say the form packageManager@x.y.z is required, so a version range will not do. Allowed values are yarn, npm and pnpm.
An optional suffix carries a hash of that version for validation, described as a SHA-224 hash. The docs call it optional but strongly recommended as a security practice.
{
"packageManager": "pnpm@9.15.0+sha224.0123abcd"
}
The version and hash above are placeholders. Take real values from your package manager's release, and let the tool write the field for you where it can.
Why this is a patching tool
An unpinned package manager is an unpatched one in practice. A developer who installed pnpm two years ago keeps running it. Pinning gives you one place to bump, and a pull request showing the change.
The hash adds a second benefit: if the downloaded package manager does not match, validation fails instead of running unknown code.
A caveat on availability
The readme says Corepack is distributed with Node.js from version 14.19.0 up to, but not including, 25.0.0. It does not say more about later versions in the text we reviewed. If you run Node.js 25 or newer, such as the current v26, check how your setup gets the package manager and install Corepack explicitly if you want this workflow.
A rollout plan
- Choose the package manager and exact version.
- Add the packageManager field with a hash.
- Update CI to enable Corepack, or install it, before install steps.
- Remove README instructions telling people to install a version by hand.
- Bump the field on a schedule, alongside Node.js reviews.
For the runtime side of this see which Node.js version should your team run.
Safeguard's dependency scanning reads your lockfile, which is the real record of what installs. A free scan is at gold.safeguard.sh/scan.
Common mistakes
The usual slips are writing a range instead of an exact version, forgetting to enable Corepack in CI so the pinned version is ignored, and committing a hash that does not belong to the version named. Another is mixing lockfiles: if the field says pnpm but someone runs npm install, you get a second lockfile and two sources of truth. Add a CI step that fails when an unexpected lockfile appears.
When you bump the field, change the lockfile in the same pull request so reviewers see both moves together.
Quick check
Can packageManager be a version range?
No. The docs say packageManager@x.y.z is required, meaning an exact version.
Is the hash required?
It is optional, but the documentation strongly recommends it as a security practice.
Sources
Last reviewed: 19 October 2026.
