@@ -12,139 +12,10 @@ added: |
12 | 12 |
|
13 | 13 | > Stability: 1 - Experimental |
14 | 14 |
|
15 | | -_[Corepack][Corepack repository]_ is an experimental tool to help with |
16 | | -managing versions of your package managers. It exposes binary proxies for |
17 | | -each [supported package manager][] that, when called, will identify whatever |
18 | | -package manager is configured for the current project, download it if needed, |
19 | | -and finally run it. |
| 15 | +Documentation for this tool can be found on the [Corepack repository][]. |
20 | 16 |
|
21 | 17 | Despite Corepack being distributed with default installs of Node.js, the package |
22 | | -managers managed by Corepack are not part of the Node.js distribution and: |
| 18 | +managers managed by Corepack are not part of the Node.js distribution, and |
| 19 | +Corepack itself will no longer be distributed with future versions of Node.js. |
23 | 20 |
|
24 | | -* Upon first use, Corepack downloads the latest version from the network. |
25 | | -* Any required updates (related to security vulnerabilities or otherwise) are |
26 | | - out of scope of the Node.js project. If necessary end users must figure out |
27 | | - how to update on their own. |
28 | | - |
29 | | -This feature simplifies two core workflows: |
30 | | - |
31 | | -* It eases new contributor onboarding, since they won't have to follow |
32 | | - system-specific installation processes anymore just to have the package |
33 | | - manager you want them to. |
34 | | - |
35 | | -* It allows you to ensure that everyone in your team will use exactly the |
36 | | - package manager version you intend them to, without them having to |
37 | | - manually synchronize it each time you need to make an update. |
38 | | - |
39 | | -## Workflows |
40 | | - |
41 | | -### Enabling the feature |
42 | | - |
43 | | -Due to its experimental status, Corepack currently needs to be explicitly |
44 | | -enabled to have any effect. To do that, run [`corepack enable`][], which |
45 | | -will set up the symlinks in your environment next to the `node` binary |
46 | | -(and overwrite the existing symlinks if necessary). |
47 | | - |
48 | | -From this point forward, any call to the [supported binaries][] will work |
49 | | -without further setup. Should you experience a problem, run |
50 | | -[`corepack disable`][] to remove the proxies from your system (and consider |
51 | | -opening an issue on the [Corepack repository][] to let us know). |
52 | | - |
53 | | -### Configuring a package |
54 | | - |
55 | | -The Corepack proxies will find the closest [`package.json`][] file in your |
56 | | -current directory hierarchy to extract its [`"packageManager"`][] property. |
57 | | - |
58 | | -If the value corresponds to a [supported package manager][], Corepack will make |
59 | | -sure that all calls to the relevant binaries are run against the requested |
60 | | -version, downloading it on demand if needed, and aborting if it cannot be |
61 | | -successfully retrieved. |
62 | | - |
63 | | -You can use [`corepack use`][] to ask Corepack to update your local |
64 | | -`package.json` to use the package manager of your choice: |
65 | | - |
66 | | -```bash |
67 | | - |
68 | | -corepack use yarn@* # sets the latest version in the package.json |
69 | | -``` |
70 | | - |
71 | | -### Upgrading the global versions |
72 | | - |
73 | | -When running outside of an existing project (for example when running |
74 | | -`yarn init`), Corepack will by default use predefined versions roughly |
75 | | -corresponding to the latest stable releases from each tool. Those versions can |
76 | | -be overridden by running the [`corepack install`][] command along with the |
77 | | -package manager version you wish to set: |
78 | | - |
79 | | -```bash |
80 | | - |
81 | | -``` |
82 | | - |
83 | | -Alternately, a tag or range may be used: |
84 | | - |
85 | | -```bash |
86 | | -corepack install --global pnpm@* |
87 | | -corepack install --global yarn@stable |
88 | | -``` |
89 | | - |
90 | | -### Offline workflow |
91 | | - |
92 | | -Many production environments don't have network access. Since Corepack |
93 | | -usually downloads the package manager releases straight from their registries, |
94 | | -it can conflict with such environments. To avoid that happening, call the |
95 | | -[`corepack pack`][] command while you still have network access (typically at |
96 | | -the same time you're preparing your deploy image). This will ensure that the |
97 | | -required package managers are available even without network access. |
98 | | - |
99 | | -The `pack` command has [various flags][]. Consult the detailed |
100 | | -[Corepack documentation][] for more information. |
101 | | - |
102 | | -## Supported package managers |
103 | | - |
104 | | -The following binaries are provided through Corepack: |
105 | | - |
106 | | -| Package manager | Binary names | |
107 | | -| --------------- | ----------------- | |
108 | | -| [Yarn][] | `yarn`, `yarnpkg` | |
109 | | -| [pnpm][] | `pnpm`, `pnpx` | |
110 | | - |
111 | | -## Common questions |
112 | | - |
113 | | -### How does Corepack interact with npm? |
114 | | - |
115 | | -While Corepack could support npm like any other package manager, its |
116 | | -shims aren't enabled by default. This has a few consequences: |
117 | | - |
118 | | -* It's always possible to run a `npm` command within a project configured to |
119 | | - be used with another package manager, since Corepack cannot intercept it. |
120 | | - |
121 | | -* While `npm` is a valid option in the [`"packageManager"`][] property, the |
122 | | - lack of shim will cause the global npm to be used. |
123 | | - |
124 | | -### Running `npm install -g yarn` doesn't work |
125 | | - |
126 | | -npm prevents accidentally overriding the Corepack binaries when doing a global |
127 | | -install. To avoid this problem, consider one of the following options: |
128 | | - |
129 | | -* Don't run this command; Corepack will provide the package manager |
130 | | - binaries anyway and will ensure that the requested versions are always |
131 | | - available, so installing the package managers explicitly isn't needed. |
132 | | - |
133 | | -* Add the `--force` flag to `npm install`; this will tell npm that it's fine to |
134 | | - override binaries, but you'll erase the Corepack ones in the process. (Run |
135 | | - [`corepack enable`][] to add them back.) |
136 | | - |
137 | | -[Corepack documentation]: https://github.com/nodejs/corepack#readme |
138 | 21 | [Corepack repository]: https://github.com/nodejs/corepack |
139 | | -[Yarn]: https://yarnpkg.com |
140 | | -[`"packageManager"`]: packages.md#packagemanager |
141 | | -[`corepack disable`]: https://github.com/nodejs/corepack#corepack-disable--name |
142 | | -[`corepack enable`]: https://github.com/nodejs/corepack#corepack-enable--name |
143 | | -[`corepack install`]: https://github.com/nodejs/corepack#corepack-install--g--global---all--nameversion |
144 | | -[`corepack pack`]: https://github.com/nodejs/corepack#corepack-pack---all--nameversion |
145 | | -[`corepack use`]: https://github.com/nodejs/corepack#corepack-use-nameversion |
146 | | -[`package.json`]: packages.md#nodejs-packagejson-field-definitions |
147 | | -[pnpm]: https://pnpm.io |
148 | | -[supported binaries]: #supported-package-managers |
149 | | -[supported package manager]: #supported-package-managers |
150 | | -[various flags]: https://github.com/nodejs/corepack#utility-commands |