<img src="./icon.svg" height="25" /> corepack

Corepack is a zero-runtime-dependency Node.js script that acts as a bridge between Node.js projects and the package managers they are intended to be used with during development. In practical terms, Corepack lets you use Yarn, npm, and pnpm without having to install them.

How to Install

Default Installs

Corepack is distributed with Node.js from version 14.19.0 up to (but not including) 25.0.0. Run corepack enable to install the required Yarn and pnpm binaries on your path.

Manual Installs

<details> <summary>Install Corepack using npm</summary>

First uninstall your global Yarn and pnpm binaries (just leave npm). In general, you'd do this by running the following command:

npm uninstall -g yarn pnpm

# That should be enough, but if you installed Yarn without going through npm it might
# be more tedious - for example, you might need to run `brew uninstall yarn` as well.

Then install Corepack:

npm install -g corepack

We do acknowledge the irony and overhead of using npm to install Corepack, which is at least part of why the preferred option is to use the Corepack version that is distributed along with Node.js itself.

</details> <details><summary>Update Corepack using npm</summary>

To install the latest version of Corepack, use:

npm install -g corepack@latest

If Corepack was installed on your system using a Node.js Windows Installer .msi package then you might need to remove it before attempting to install a different version of Corepack using npm. You can select the Modify option of the Node.js app settings to access the Windows Installer feature selection, and on the "corepack manager" feature of the Node.js .msi package by selecting "Entire feature will be unavailable". See Repair apps and programs in Windows for instructions on accessing the Windows apps page to modify settings.

</details> <details><summary>Install Corepack from source</summary>

See CONTRIBUTING.md.

</details>

Usage

When Building Packages

Just use your package managers as you usually would. Run yarn install in Yarn projects, pnpm install in pnpm projects, and npm in npm projects. Corepack will catch these calls, and depending on the situation:

If the local project is configured for the package manager you're using, Corepack will download and cache the latest compatible version.
If the local project is configured for a different package manager, Corepack will request you to run the command again using the right package manager - thus avoiding corruptions of your install artifacts.
If the local project isn't configured for any package manager, Corepack will assume that you know what you're doing, and will use whatever package manager version has been pinned as "known good release". Check the relevant section for more details.

When Authoring Packages

Set your package's manager with the packageManager field in package.json:

{
  "packageManager": "yarn@3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa"
}

Here, yarn is the name of the package manager, specified at version 3.2.3, along with the SHA-224 hash of this version for validation. packageManager@x.y.z is required. The hash is optional but strongly recommended as a security practice. Permitted values for the package manager are yarn, npm, and pnpm.

You can also provide a URL to a .js file (which will be interpreted as a CommonJS module) or a .tgz file (which will be interpreted as a package, and the "bin" field of the package.json will be used to determine which file to use in the archive).

{
  "packageManager": "yarn@https://registry.npmjs.org/@yarnpkg/cli-dist/-/cli-dist-3.2.3.tgz#sha224.16a0797d1710d1fb7ec40ab5c3801b68370a612a9b66ba117ad9924b"
}

`devEngines.packageManager`

When a devEngines.packageManager field is defined, and is an object containing a "name" field (can also optionally contain version and onFail fields), Corepack will use it to validate you're using a compatible package manager.

Depending on the value of devEngines.packageManager.onFail:

if set to ignore, Corepack won't print any warning or error.
if unset or set to error, Corepack will throw an error in case of a mismatch.
if set to warn or some other value, Corepack will print a warning in case of mismatch.

If the top-level packageManager field is missing, Corepack will use the package manager defined in devEngines.packageManager – in which case you must provide a specific version in devEngines.packageManager.version, ideally with a hash, as explained in the previous section:

{
  "devEngines":{
    "packageManager": {
      "name": "yarn",
      "version": "3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa"
    }
  }
}

Known Good Releases

When running Corepack within projects that don't list a supported package manager, it will default to a set of Known Good Releases.

If there is no Known Good Release for the requested package manager, Corepack looks up the npm registry for the latest available version and cache it for future use.

The Known Good Releases can be updated system-wide using corepack install -g. When Corepack downloads a new version of a given package manager on the same major line as the Known Good Release, it auto-updates it by default.

Offline Workflow

The utility commands detailed in the next section.

Either you can use the network while building your container image, in which case you'll simply run corepack pack to make sure that your image includes the Last Known Good release for the specified package manager.
Or you're publishing your project to a system where the network is unavailable, in which case you'll preemptively generate a package manager archive from your local computer (using corepack pack -o) before storing it somewhere your container will be able to access (for example within your repository). After that it'll just be a matter of running corepack install -g --cache-only <path/to/corepack.tgz> to setup the cache.

Utility Commands

`corepack <binary name>[@<version>] [... args]`

This meta-command runs the specified package manager in the local folder. You can use it to force an install to run with a given version, which can be useful when looking for regressions.

Note that those commands still check whether the local project is configured for the given package manager (ie you won't be able to run corepack yarn install on a project where the packageManager field references pnpm).

`corepack cache clean`

Clears the local COREPACK_HOME cache directory.

`corepack cache clear`

Clears the local COREPACK_HOME cache directory.

`corepack enable [... name]`

| Option | Description | | --------------------- | --------------------------------------- | | --install-directory | Add the shims to the specified location |

This command will detect where Corepack is installed and will create shims next to it for each of the specified package managers (or all of them if the command is called without parameters). Note that the npm shims will not be installed unless explicitly requested, as npm is currently distributed with Node.js through other means.

If the file system where the corepack binary is located is read-only, this command will fail. A workaround is to add the binaries as alias in your shell configuration file (e.g. in ~/.bash_aliases):

alias yarn="corepack yarn"
alias yarnpkg="corepack yarnpkg"
alias pnpm="corepack pnpm"
alias pnpx="corepack pnpx"
alias npm="corepack npm"
alias npx="corepack npx"

On Windows PowerShell, you can add functions using the $PROFILE automatic variable:

echo 'function yarn { corepack yarn @args }'    >> $PROFILE
echo 'function yarnpkg { corepack yarnpkg @args }' >> $PROFILE
echo 'function pnpm { corepack pnpm @args }'    >> $PROFILE
echo 'function pnpx { corepack pnpx @args }'    >> $PROFILE
echo 'function npm { corepack npm @args }'      >> $PROFILE
echo 'function npx { corepack npx @args }'      >> $PROFILE

`corepack disable [... name]`

| Option | Description | | --------------------- | ------------------------------------------ | | --install-directory | Remove the shims to the specified location |

This command will detect where Node.js is installed and will remove the shims from there.

`corepack install`

Download and install the package manager configured in the local project. This command doesn't change the global version used when running the package manager from outside the project (use the `-g,--global` flag if you wish to do this).

`corepack install <-g,--global> [... name[@<version>]]`

Install the selected package managers and install them on the system.

Package managers thus installed will be configured as the new default when calling their respective binaries outside of projects defining the packageManager field.

`corepack pack [... name[@<version>]]`

| Option | Description | | --------------------- | ------------------------------------------ | | --json | Print the output folder rather than logs | | -o,--output | Path where to generate the archive |

Download the selected package managers and store them inside a tarball suitable for use with corepack install -g.

`corepack use <name[@<version>]>`

When run, this command will re

Corepack

Install / Use

README