@@ -92,26 +92,25 @@ If there is no Known Good Release for the requested package manager, Corepack |
92 | 92 | looks up the npm registry for the latest available version and cache it for |
93 | 93 | future use. |
94 | 94 |
|
95 | | -The Known Good Releases can be updated system-wide using the `--activate` flag |
96 | | -from the `corepack prepare` and `corepack hydrate` commands. |
| 95 | +The Known Good Releases can be updated system-wide using `corepack install -g`. |
97 | 96 |
|
98 | 97 | ## Offline Workflow |
99 | 98 |
|
100 | 99 | The utility commands detailed in the next section. |
101 | 100 |
|
102 | 101 | - Either you can use the network while building your container image, in which |
103 | | - case you'll simply run `corepack prepare` to make sure that your image |
| 102 | + case you'll simply run `corepack pack` to make sure that your image |
104 | 103 | includes the Last Known Good release for the specified package manager. |
105 | 104 |
|
106 | 105 | - If you want to have _all_ Last Known Good releases for all package managers, |
107 | 106 | just use the `--all` flag which will do just that. |
108 | 107 |
|
109 | 108 | - Or you're publishing your project to a system where the network is |
110 | 109 | unavailable, in which case you'll preemptively generate a package manager |
111 | | - archive from your local computer (using `corepack prepare -o`) before storing |
| 110 | + archive from your local computer (using `corepack pack -o`) before storing |
112 | 111 | it somewhere your container will be able to access (for example within your |
113 | 112 | repository). After that it'll just be a matter of running |
114 | | - `corepack hydrate <path/to/corepack.tgz>` to setup the cache. |
| 113 | + `corepack install -g --cache-only <path/to/corepack.tgz>` to setup the cache. |
115 | 114 |
|
116 | 115 | ## Utility Commands |
117 | 116 |
|
@@ -171,29 +170,52 @@ echo "function npx { corepack npx `$args }" >> $PROFILE |
171 | 170 | This command will detect where Node.js is installed and will remove the shims |
172 | 171 | from there. |
173 | 172 |
|
174 | | -### `corepack prepare [... name@version]` |
| 173 | +### `corepack install` |
175 | 174 |
|
176 | | -| Option | Description | |
177 | | -| ------------- | ----------------------------------------------------------------------- | |
178 | | -| `--all` | Prepare the "Last Known Good" version of all supported package managers | |
179 | | -| `-o,--output` | Also generate an archive containing the package managers | |
180 | | -| `--activate` | Also update the "Last Known Good" release | |
| 175 | +Download and install the package manager configured in the local project. |
| 176 | +This command doesn't change the global version used when running the package |
| 177 | +manager from outside the project (use the \`-g,--global\` flag if you wish |
| 178 | +to do this). |
181 | 179 |
|
182 | | -This command will download the given package managers (or the one configured for |
183 | | -the local project if no argument is passed in parameter) and store it within the |
184 | | -Corepack cache. If the `-o,--output` flag is set (optionally with a path as |
185 | | -parameter), an archive will also be generated that can be used by the |
186 | | -`corepack hydrate` command. |
| 180 | +### `corepack install <-g,--global> [--all] [... name@version]` |
187 | 181 |
|
188 | | -### `corepack hydrate <path/to/corepack.tgz>` |
| 182 | +| Option | Description | |
| 183 | +| --------------------- | ------------------------------------------ | |
| 184 | +| `--all` | Install all Last Known Good releases | |
| 185 | + |
| 186 | +Install the selected package managers and install them on the system. |
| 187 | + |
| 188 | +Package managers thus installed will be configured as the new default when |
| 189 | +calling their respective binaries outside of projects defining the |
| 190 | +`packageManager` field. |
| 191 | + |
| 192 | +### `corepack pack [--all] [... name@version]` |
| 193 | + |
| 194 | +| Option | Description | |
| 195 | +| --------------------- | ------------------------------------------ | |
| 196 | +| `--all` | Pack all Last Known Good releases | |
| 197 | +| `--json ` | Print the output folder rather than logs | |
| 198 | +| `-o,--output ` | Path where to generate the archive | |
| 199 | + |
| 200 | +Download the selected package managers and store them inside a tarball |
| 201 | +suitable for use with `corepack install -g`. |
| 202 | + |
| 203 | +### `corepack use <name@version>` |
| 204 | + |
| 205 | +When run, this command will retrieve the latest release matching the provided |
| 206 | +descriptor, assign it to the project's package.json file, and automatically |
| 207 | +perform an install. |
| 208 | + |
| 209 | +### `corepack up` |
189 | 210 |
|
190 | | -| Option | Description | |
191 | | -| ------------ | ----------------------------------------- | |
192 | | -| `--activate` | Also update the "Last Known Good" release | |
| 211 | +Retrieve the latest available version for the current major release line of |
| 212 | +the package manager used in the local project, and update the project to use |
| 213 | +it. |
193 | 214 |
|
194 | | -This command will retrieve the given package manager from the specified archive |
195 | | -and will install it within the Corepack cache, ready to be used without further |
196 | | -network interaction. |
| 215 | +Unlike `corepack use` this command doesn't take a package manager name nor a |
| 216 | +version range, as it will always select the latest available version from the |
| 217 | +same major line. Should you need to upgrade to a new major, use an explicit |
| 218 | +`corepack use {name}@latest` call. |
197 | 219 |
|
198 | 220 | ## Environment Variables |
199 | 221 |
|
@@ -204,7 +226,7 @@ network interaction. |
204 | 226 | - `COREPACK_ENABLE_NETWORK` can be set to `0` to prevent Corepack from accessing |
205 | 227 | the network (in which case you'll be responsible for hydrating the package |
206 | 228 | manager versions that will be required for the projects you'll run, using |
207 | | - `corepack hydrate`). |
| 229 | + `corepack install -g --cache-only`). |
208 | 230 |
|
209 | 231 | - `COREPACK_ENABLE_STRICT` can be set to `0` to prevent Corepack from throwing |
210 | 232 | error if the package manager does not correspond to the one defined for the |
|