@@ -81,18 +81,29 @@ along with the SHA-224 hash of this version for validation. |
81 | 81 | recommended as a security practice. Permitted values for the package manager are |
82 | 82 | `yarn`, `npm`, and `pnpm`. |
83 | 83 |
|
| 84 | +You can also provide a URL to a `.js` file (which will be interpreted as a |
| 85 | +CommonJS module) or a `.tgz` file (which will be interpreted as a package, and |
| 86 | +the `"bin"` field of the `package.json` will be used to determine which file to |
| 87 | +use in the archive). |
| 88 | + |
| 89 | +```json |
| 90 | +{ |
| 91 | + "packageManager": "yarn@https://registry.npmjs.org/@yarnpkg/cli-dist/-/cli-dist-3.2.3.tgz#sha224.16a0797d1710d1fb7ec40ab5c3801b68370a612a9b66ba117ad9924b" |
| 92 | +} |
| 93 | +``` |
| 94 | + |
84 | 95 | ## Known Good Releases |
85 | 96 |
|
86 | 97 | When running Corepack within projects that don't list a supported package |
87 | | -manager, it will default to a set of Known Good Releases. In a way, you can |
88 | | -compare this to Node.js, where each version ships with a specific version of |
89 | | -npm. |
| 98 | +manager, it will default to a set of Known Good Releases. |
90 | 99 |
|
91 | 100 | If there is no Known Good Release for the requested package manager, Corepack |
92 | 101 | looks up the npm registry for the latest available version and cache it for |
93 | 102 | future use. |
94 | 103 |
|
95 | 104 | The Known Good Releases can be updated system-wide using `corepack install -g`. |
| 105 | +When Corepack downloads a new version of a given package manager on the same |
| 106 | +major line as the Known Good Release, it auto-updates it by default. |
96 | 107 |
|
97 | 108 | ## Offline Workflow |
98 | 109 |
|
@@ -102,9 +113,6 @@ The utility commands detailed in the next section. |
102 | 113 | case you'll simply run `corepack pack` to make sure that your image |
103 | 114 | includes the Last Known Good release for the specified package manager. |
104 | 115 |
|
105 | | - - If you want to have _all_ Last Known Good releases for all package managers, |
106 | | - just use the `--all` flag which will do just that. |
107 | | - |
108 | 116 | - Or you're publishing your project to a system where the network is |
109 | 117 | unavailable, in which case you'll preemptively generate a package manager |
110 | 118 | archive from your local computer (using `corepack pack -o`) before storing |
@@ -124,6 +132,14 @@ Note that those commands still check whether the local project is configured for |
124 | 132 | the given package manager (ie you won't be able to run `corepack yarn install` |
125 | 133 | on a project where the `packageManager` field references `pnpm`). |
126 | 134 |
|
| 135 | +### `corepack cache clean` |
| 136 | + |
| 137 | +Clears the local `COREPACK_HOME` cache directory. |
| 138 | + |
| 139 | +### `corepack cache clear` |
| 140 | + |
| 141 | +Clears the local `COREPACK_HOME` cache directory. |
| 142 | + |
127 | 143 | ### `corepack enable [... name]` |
128 | 144 |
|
129 | 145 | | Option | Description | |
@@ -177,23 +193,18 @@ This command doesn't change the global version used when running the package |
177 | 193 | manager from outside the project (use the \`-g,--global\` flag if you wish |
178 | 194 | to do this). |
179 | 195 |
|
180 | | -### `corepack install <-g,--global> [--all] [... name[@<version>]]` |
181 | | - |
182 | | -| Option | Description | |
183 | | -| --------------------- | ------------------------------------------ | |
184 | | -| `--all` | Install all Last Known Good releases | |
| 196 | +### `corepack install <-g,--global> [... name[@<version>]]` |
185 | 197 |
|
186 | 198 | Install the selected package managers and install them on the system. |
187 | 199 |
|
188 | 200 | Package managers thus installed will be configured as the new default when |
189 | 201 | calling their respective binaries outside of projects defining the |
190 | 202 | `packageManager` field. |
191 | 203 |
|
192 | | -### `corepack pack [--all] [... name[@<version>]]` |
| 204 | +### `corepack pack [... name[@<version>]]` |
193 | 205 |
|
194 | 206 | | Option | Description | |
195 | 207 | | --------------------- | ------------------------------------------ | |
196 | | -| `--all` | Pack all Last Known Good releases | |
197 | 208 | | `--json ` | Print the output folder rather than logs | |
198 | 209 | | `-o,--output ` | Path where to generate the archive | |
199 | 210 |
|
@@ -221,7 +232,20 @@ same major line. Should you need to upgrade to a new major, use an explicit |
221 | 232 |
|
222 | 233 | - `COREPACK_DEFAULT_TO_LATEST` can be set to `0` in order to instruct Corepack |
223 | 234 | not to lookup on the remote registry for the latest version of the selected |
224 | | - package manager. |
| 235 | + package manager, and to not update the Last Known Good version when it |
| 236 | + downloads a new version of the same major line. |
| 237 | + |
| 238 | +- `COREPACK_ENABLE_DOWNLOAD_PROMPT` can be set to `0` to |
| 239 | + prevent Corepack showing the URL when it needs to download software, or can be |
| 240 | + set to `1` to have the URL shown. By default, when Corepack is called |
| 241 | + explicitly (e.g. `corepack pnpm …`), it is set to `0`; when Corepack is called |
| 242 | + implicitely (e.g. `pnpm …`), it is set to `1`. |
| 243 | + When standard input is a TTY and no CI environment is detected, Corepack will |
| 244 | + ask for user input before starting the download. |
| 245 | + |
| 246 | +- `COREPACK_ENABLE_UNSAFE_CUSTOM_URLS` can be set to `1` to allow use of |
| 247 | + custom URLs to load a package manager known by Corepack (`yarn`, `npm`, and |
| 248 | + `pnpm`). |
225 | 249 |
|
226 | 250 | - `COREPACK_ENABLE_NETWORK` can be set to `0` to prevent Corepack from accessing |
227 | 251 | the network (in which case you'll be responsible for hydrating the package |
|