-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: download the latest version instead of a pinned one #134
Changes from 4 commits
88f6807
6c9e041
0668fb0
c33fa1d
12a91f9
4ce5e2c
9563bcd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -46,9 +46,16 @@ Just use your package managers as you usually would. Run `yarn install` in Yarn | |
|
||
## Known Good Releases | ||
|
||
When running Yarn or pnpm within projects that don't list a supported package manager, Corepack will default to a set of Known Good Releases. In a way, you can compare this to Node.js, where each version ships with a specific version of npm. | ||
When running Corepack within projects that don't list a supported package | ||
manager, it will default to a set of Known Good Releases. In a way, you can | ||
compare this to Node.js, where each version ships with a specific version of npm. | ||
|
||
The Known Good Releases can be updated system-wide using the `--activate` flag from the `corepack prepare` and `corepack hydrate` commands. | ||
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 the `--activate` flag | ||
from the `corepack prepare` and `corepack hydrate` commands. | ||
|
||
## Offline Workflow | ||
|
||
|
@@ -106,6 +113,8 @@ This command will retrieve the given package manager from the specified archive | |
|
||
- `COREPACK_ENABLE_NETWORK` can be set to `0` to prevent Corepack from accessing the network (in which case you'll be responsible for hydrating the package manager versions that will be required for the projects you'll run, using `corepack hydrate`). | ||
|
||
- `COREPACK_NO_LOOKUP` can be set in order to instruct Corepack not to lookup on the remote registry for the latest version of the selected package manager. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should probably find a better name for this env variable, I don't think one could infer what it's doing from the name only. Does anyone has suggestions? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm trying to understand the difference between There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's only internals, bundled in the corepack executable. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about COREPACK_IGNORE_LATEST? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I went with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure about using “default” as a verb here. How about COREPACK_ENABLE_FETCH_LATEST=0 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd like the naming to make clear that it's only relevant if there's no local clue on what version to use.
I'm not a native english speaker, so genuine question: is it incorrect or something to use "default" as a verb? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It’s not incorrect, just that “default” can be a verb or a noun. It’s probably fine 👍 |
||
|
||
- `COREPACK_HOME` can be set in order to define where Corepack should install the package managers. By default it is set to `$HOME/.node/corepack`. | ||
|
||
- `COREPACK_ROOT` has no functional impact on Corepack itself; it's automatically being set in your environment by Corepack when it shells out to the underlying package managers, so that they can feature-detect its presence (useful for commands like `yarn init`). | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,6 +9,23 @@ import * as httpUtils from './httpUtils | |
import * as nodeUtils from './nodeUtils'; | ||
import {RegistrySpec, Descriptor, Locator, PackageManagerSpec} from './types'; | ||
|
||
export async function fetchLatestStableVersion(spec: RegistrySpec) { | ||
switch (spec.type) { | ||
case `npm`: { | ||
const {[`dist-tags`]: {latest}, versions: {[latest]: {dist: {shasum}}}} = | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this consider the major version? What about when npm 7 bumped to npm 8 to drop support for node 12. Imagine if corepack existed then and suddenly npm stopped working because of the automatic fetch latest. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That’s worth discussing, but imo it’s ok to ignore that for the initial implementation. |
||
await httpUtils.fetchAsJson(`https://registry.npmjs.org/${spec.package}`); | ||
return `${latest}+sha1.${shasum}`; | ||
} | ||
case `url`: { | ||
const data = await httpUtils.fetchAsJson(spec.url); | ||
return data[spec.fields.tags].stable; | ||
} | ||
default: { | ||
throw new Error(`Unsupported specification ${JSON.stringify(spec)}`); | ||
} | ||
} | ||
} | ||
|
||
export async function fetchAvailableTags(spec: RegistrySpec): Promise<Record<string, string>> { | ||
switch (spec.type) { | ||
case `npm`: { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In what case would there be no Known Good Release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon the first time Corepack is run with a given package manager. The idea behind this PR would be not to rely on what version is set on
config.json
but instead get the most up-to-date version from npm registry.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How often does it check the registry? Does it check every time you invoke yarn/pnpm/npm because that seems slow. Especially if I just want to do
npm run <script>
which should work offline.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, only the first time, at which point it saves it as Known Good Release. Users can then update (or downgrade) that version by using
corepack prepare
orcorepack hydrate
(e.g.corepack prepare pnpm@latest --activate
to get the latest pnpm by default). We could make an automated process for the Known Good Version to expire after some time, but that's not part of this initial implementation.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I understand now 👍
I think expiring would could be confusing. I also think this any auto update could be confusing because it no longer ties the package manager version to the corepack version (or node version for that matter).
I think it’s best to let the user decide when to upgrade and perhaps provide better docs how to upgrade (this isn’t super clear today). Without corepack, this is handled with a notification that says something like npm i -g npm@latest.
Has any of this behavior been reviewed by the npm team? I think they had some ideas about Know Good Release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well that's the reason Corepack exists, because the Node.js TSC doesn't want to have specific version of a package manager tied in with a specific Node.js version – specifically, several Node.js TSC members have expressed that the reason they are supportive of Corepack is to get rid of having to do security releases every time a vulnerability is reported in npm rather than
node
itself.So the auto-lookup during the first use has to be the default behavior.
Yes that makes sense, letting the end-user in control is very much the goal here. So instead of
npm i -g npm@latest
, users would typecorepack prepare npm@latest --activate
, which is arguably quite similar. Improving docs is of course always a goal.The npm team hasn't shown much interest in the development of Corepack, so I don't think they have.