1# Corepack 2 3<!-- introduced_in=v14.19.0 --> 4<!-- type=misc --> 5 6> Stability: 1 - Experimental 7 8_[Corepack][]_ is an experimental tool to help with 9managing versions of your package managers. It exposes binary proxies for 10each [supported package manager][] that, when called, will identify whatever 11package manager is configured for the current project, transparently install 12it if needed, and finally run it without requiring explicit user interactions. 13 14This feature simplifies two core workflows: 15 16* It eases new contributor onboarding, since they won't have to follow 17 system-specific installation processes anymore just to have the package 18 manager you want them to. 19 20* It allows you to ensure that everyone in your team will use exactly the 21 package manager version you intend them to, without them having to 22 manually synchronize it each time you need to make an update. 23 24## Workflows 25 26### Enabling the feature 27 28Due to its experimental status, Corepack currently needs to be explicitly 29enabled to have any effect. To do that simply run [`corepack enable`][], which 30will set up the symlinks in your environment, next to the `node` binary 31(and overwrite the existing symlinks if necessary). 32 33From this point forward, any call to the [supported binaries][] will work 34without further setup. Should you experience a problem, just run 35[`corepack disable`][] to remove the proxies from your system (and consider 36opening up an issue on the [Corepack repository][] to let us know). 37 38### Configuring a package 39 40The Corepack proxies will find the closest [`package.json`][] file in your 41current directory hierarchy to extract its [`"packageManager"`][] property. 42 43If the value corresponds to a [supported package manager][], Corepack will make 44sure that all calls to the relevant binaries are run against the requested 45version, downloading it on demand if needed, and aborting if it cannot be 46successfully retrieved. 47 48### Upgrading the global versions 49 50When running outside of an existing project (for example when running 51`yarn init`), Corepack will by default use predefined versions roughly 52corresponding to the latest stable releases from each tool. Those versions can 53be easily overriden by running the [`corepack prepare`][] command along with the 54package manager version you wish to set: 55 56```bash 57corepack prepare yarn@x.y.z --activate 58``` 59 60### Offline workflow 61 62Many production environments don't have network access. Since Corepack 63usually downloads the package manager releases straight from their registries, 64it can conflict with such environments. To avoid that happening, call the 65[`corepack prepare`][] command while you still have network access (typically at 66the same time you're preparing your deploy image). This will ensure that the 67required package managers are available even without network access. 68 69The `prepare` command has [various flags][], consult the detailed 70[Corepack documentation][] for more information on the matter. 71 72## Supported package managers 73 74The following binaries are provided through Corepack: 75 76| Package manager | Binary names | 77| --------------- | -------------- | 78| [Yarn][] | `yarn`, `yarnpkg` | 79| [pnpm][] | `pnpm`, `pnpx` | 80 81## Common questions 82 83### How does Corepack currently interact with npm? 84 85While Corepack could easily support npm like any other package manager, its 86shims aren't currently enabled by default. This has a few consequences: 87 88* It's always possible to run a `npm` command within a project configured to 89be used with another package manager, since Corepack cannot intercept it. 90 91* While `npm` is a valid option in the [`"packageManager"`][] property, the 92lack of shim will cause the global npm to be used. 93 94### Running `npm install -g yarn` doesn't work 95 96npm prevents accidentally overriding the Corepack binaries when doing a global 97install. To avoid this problem, consider one of the following options: 98 99* Don't run this command anymore; Corepack will provide the package manager 100binaries anyway and will ensure that the requested versions are always 101available, so installing the package managers explicitly isn't needed anymore. 102 103* Add the `--force` flag to `npm install`; this will tell npm that it's fine to 104override binaries, but you'll erase the Corepack ones in the process (should 105that happen, run [`corepack enable`][] again to add them back). 106 107[Corepack]: https://github.com/nodejs/corepack 108[Corepack documentation]: https://github.com/nodejs/corepack#readme 109[Corepack repository]: https://github.com/nodejs/corepack 110[Yarn]: https://yarnpkg.com 111[`"packageManager"`]: packages.md#packages_packagemanager 112[`corepack disable`]: https://github.com/nodejs/corepack#corepack-disable--name 113[`corepack enable`]: https://github.com/nodejs/corepack#corepack-enable--name 114[`corepack prepare`]: https://github.com/nodejs/corepack#corepack-prepare--nameversion 115[`package.json`]: packages.md#packages_node_js_package_json_field_definitions 116[pnpm]: https://pnpm.js.org 117[supported binaries]: #corepack_supported_package_managers 118[supported package manager]: #corepack_supported_package_managers 119[various flags]: https://github.com/nodejs/corepack#utility-commands 120