Repository navigation
Project Status (experimental to stable?) #104
Description
Activity
I’d hope for security that corepack starts checking integrity hashes before it’s enabled by default.
(Edit: This was briefly fixed, but it was then reversed by #134 and remains a problem.)
Reacted by Steven, Antoine du Hamel and Josh W LewisVisiting this GitHub issue from twitter thread.
I'd asked on Yarn Discord in Jan'22 if we should propose to make it stable in Node.js 18. There was no follow-up though.
Some useful links:
- Corepack was backported to
v14.19.0in v14.19.0 proposal node#41696 - Criteria for n-api to exit experimental status node#14532
- Discussion: Exit criteria for bringing http2 out of experimental node#19453
@arcanis has been the champion and lead author for corepack, along with other maintainers of yarn.
They're currently busy with the launch of yarn v4 in yarnpkg/berry#3591I think we should revive this GitHub issue after yarn v4 release.
- Corepack was backported to
Are there known breaking changes coming up?
Mostly just #93 - many Node contributors expressed interest in seeing Corepack have a slightly more dynamic behavior, so that it stay up-to-date with minor/patch versions from the package managers (look at the thread for details, but in short it's currently painful for Node to have to make new releases each time npm has a security update).
It makes dealing with #37 a little harder though. Perhaps package managers releases could be signed instead, although it requires infra and can be be difficult to do for package managers that aren't distributed as a single JS bundle (I believe only Yarn is).
Are there any outstanding blockers?
Apart from the one described above, I'd personally like to have feedback from one or more cloud provider confirming that Corepack has all the tools they need to build a proper integration that doesn't break their customers' setup. That's something Vercel can certainly help with!
Do we need to get npm working to be considered stable?
Corepack has value for Yarn and pnpm users, and it'd be too bad if we were blocked going forward by something we have no control over, so in my opinion I'd tend to say it's not needed, although it would be nice to have.
Note that technically Corepack already supports npm, it's just not part of the default distribution until they decide to enable it. So when that happens it will be fairly fast and won't require much engineering work.
Will a stable release remove the need to run corepack enable or will that always be a requirement?
My hope (and goal when building this project) is that
corepack enablewon't be needed.Reacted by Steven, Daniel Almaguer, Trivikram Kamat, Glenn 'devalias' Grant, Gabriele Tomberli, Leonardo Rocha and Kurt von LavenI'd personally like to have feedback from one or more cloud provider
We announced support today https://twitter.com/vercel_changes/status/1547581626279792640
I'll relay any feedback from our customers as they begin adoption 👍
In my own testing, the biggest problem I see today is the "Usage Error: This project is configured to use ". This happens when I run
npm i -g vercel@latestin a project that is configured to use yarn or pnpm. It seems a little too strict because the global flag is not scoped to my current project. Similarly,vercel devwill shell out tonpmornpxand corepack being enabled could block it from working properly.Update: I created #157
Reacted by Antoine du Hamel, lin72h, Gabriele Tomberli and Leonardo RochaReacted by Antoine du Hamel, lin72h and Kurt von LavenChecking in here again. I can say that all outstanding issues are complete and everyone who tries out corepack is very happy with it. Its solving real problems. For example, npm changed behavior of peer dependencies in
npm installin a minor version (8.6.0) suddenly causing builds to fail, and corepack allowed users to continue using the old behaviorThat being said, the one thing missing today is default support for npm when I run
corepack enable. However,corepack enable npmis a sufficient workaround and has proved it works well today already. I agree that this shouldn't be a blocker with going to "stable" status.Reacted by Trivikram Kamat, Antoine du Hamel, Gabriele Tomberli and stefnotchChecking in here again. I can say that all outstanding issues are complete and everyone who tries out corepack is very happy with it. Its solving real problems. For example, npm changed behavior of peer dependencies in
npm installin a minor version (8.6.0) suddenly causing builds to fail, and corepack allowed users to continue using the old behaviorThat's really good to hear!
That being said, the one thing missing today is default support for npm when I run
corepack enable. However,corepack enable npmis a sufficient workaround and has proved it works well today already. I agree that this shouldn't be a blocker with going to "stable" status.I would assume that, on the contrary, Corepack being experimental would be a blocker to switch to using it for providing npm binaries with Node.js installation (instead of vendoring npm in the node repository like we do today).
One additional thing I would personally like to see before calling Corepack stable is the ability for package manager authors to sign their releases, as a security feature. Maybe it's not a blocker though.I wouldn't consider signing releases a blocker to going stable. It would be a nice feature though.
Correct me if I'm wrong, but I don't think
npm i -g pnpm@7.13.4has signed releases either?Unless the
{ "packageManager": "pnpm@7.13.4" }config doesn't pull from the npm registry like I expected? 🤔I wouldn't consider signing releases a blocker to going stable. It would be a nice feature though.
When discussing with other devs, I've heard a few concerns regarding the decrease of security if Node.js doesn't ship npm anymore and instead expect users to download the latest version which could have been tampered with. IMO when we call Corepack stable, the next logical step is to stop bundling npm by default with Node.js in favor of Corepack, and the lack of signature verification might be a problem on that aspect.
Correct me if I'm wrong, but I don't think
npm i -g pnpm@7.13.4has signed releases either?
Unless the{ "packageManager": "pnpm@7.13.4" }config doesn't pull from the npm registry like I expected? 🤔npm, pnpm, and Yarn v1.x are pulled from the npm registry, Yarn Berry is pulled from their own server. But it doesn't have anything to do with signed releases, right?
Reacted by Leonardo RochaThis issue needs to be fixed before going stable:
Mostly time. On my side I'd like to add signing support to Yarn before asking for it to become stable, but I'm currently focusing on another Node PR.
Perhaps in the meantime we can start to gather numbers / quotes demonstrating Corepack's usefulness in the wild ? I don't know what else would help the TSC make a decision, when comes the time.
I believe there's a pretty major licensing issue that needs to be resolved as well.
What are you referring to? That doesn't ring a bell.
Reacted by StevenMy understanding is that corepack's npm "jumper" thing violates npm's license. I'm under the impression it's been brought to your attention in the past, and I'm pretty sure folks on the TSC are aware of it as well.
I for one am not aware of it, do you have a link to a discussion that explains what's the issue?
Reacted by Steven6 remaining items
Revisiting this request to make corepack stable, as both yarn and pnpm recommend their users to use corepack:
- Yarn 4.0 release notes https://yarnpkg.com/blog/release/4.0#installing-yarn
- Pnpm installation https://pnpm.io/installation#using-corepack
Some downstream dependencies, like GitHub Action to setup node, still do not support corepack actions/setup-node#651
It would be helpful for yarn/pnpm users on Node.js projects if corepack is enabled by default in Node.js.Reacted by Alexander Kachkaev, Teppei Sato, Michael Kriese, Nathan Bierema, Trey (Kasada), Christophe Hurpeau, Trey Brisbane, Steven, Percy Ma, Mike McCready and 23 moreNode.js TSC in the process of discussing and taking action for the status of the project. For more information, I recommend reading the meeting notes from January 10, 2024. nodejs/TSC#1490
Reacted by Alexander Kachkaev, Steven, Noah and KenrickThe discussion is continuing in this issue: nodejs/node#50963
Me watching from the sidelines: https://media2.giphy.com/media/FibBZ3bFGGcoXCB1kd/giphy.gif
Reacted by Trivikram Kamat, Alexander Kachkaev, Kenrick and Brian EspinosaReacted by Brian EspinosaPersonal opinion (does not represent my employer):
- +1 for corepack out of experimental to alleviate concerns
- +1 for making it clear that npm is not owned by Node.js and making it clear package managers in corepack and tools still use the npm registry by default
- +1 for keeping it opt in (
corepack enable)
Reacted by Daniel Bayley, Alexander Kachkaev, Jérémie Meyer de Ville and Brian EspinosaReacted by Steven, William Entriken and alok1111- making it clear package managers in corepack and tools still use the npm registry by default
I don't think we can guarantee that, and also I think package managers should be free to pick the package registry they want – I mean it is the case atm, Yarn and PNPM both default to the public npm registry, but future additions to Corepack might want to supply their own registry or whatever. IMO it's not reasonable to expect Corepack maintainers to audit the candidate to make any guarantees on what the software is doing.
Reacted by Steven, Eligio Mariño and William EntrikenOn 2024-03-19, the Node.js TSC voted to stop distributing corepack in Node.js v25+
I believe the experimental status, i.e. requirement to run
corepack enable, needs to be maintained till Node.js v24 goes EoL, i.e. 2028-04-30Should this issue be closed as the date is 3+ years away?
We can create a new issue to release stable version, i.e. 1.0.0, of corepack which removes the requirement of runningcorepack enableafter or close to 2028-04-30I don't believe that you can equate the experimental status with enabling Corepack by default. These were two different options in the vote.
I would personally like to see the experimental status removed from Corepack so I can use it with good conscience in production.
Alternatively there could be a statement issued, that this part of the experimental status does not apply to Corepack and the Node.js organization consents to Corepack's use in a production environment and supports its continued use through the bundled version in Node.js and as well as through the separately available module corepack from the npm registry.
Having Corepack enabled by default would be disruptive for me in a hybrid environment of projects and npm modules configured for Corepack, and others which are not. I don't control most of these environment or have any say in how they are configured. I would not like Corepack enabled to be the default even though I am using Corepack in several selected places. It's fine for me to actively enable Corepack when I need it. You already suggested opening a separate issue about enabling Corepack by default. That would be a good way to separate the topics.
FWIW if you install Corepack with
npm i -g corepack, you don't need to runcorepack enable, you getyarn,pnpm, andpnpxexecutables.My understanding was that corepack integration in Node.js distribution was experimental, not Corepack itself – although it still hasn't released a 1.0.0 version, so it falls under https://semver.org/#spec-item-4, and indeed not exactly stable (but fine to run on CI environments as long set a specific version or are happy to deal with potential breaking changes when they happen). I don't have a strong opinion regarding whether 1.0.0 should happen before or after Node.js 24.x EOL, or if we need a new issue for discussing that.
Reacted by Mike McCready and StevenFWIW if you install Corepack with
npm i -g corepack, you don't need to runcorepack enable, you getyarn,pnpm, andpnpxexecutables.I suggest that this information should be added to the README. I don't think that it is obvious that
npm i -g corepackis like executingcorepack enable.For instance if I have Node.js
22.14.0LTS with the bundledcorepack@0.31.0installed, Corepack is disabled. If I then install the same version on top, then Corepack is enabled:npm i -g corepack@0.31.0
Edit: If Corepack is always disabled by default in the Node.js bundled distribution and enabled when installed separately as an npm global install that works for me.
My understanding was that corepack integration in Node.js distribution was experimental, not Corepack itself – although it still hasn't released a 1.0.0 version, so it falls under https://semver.org/#spec-item-4, and indeed not exactly stable (but fine to run on CI environments as long set a specific version or are happy to deal with potential breaking changes when they happen).
Thanks for this additional information! 👍🏻
As per recent responses, it appears that this issue can be closed as "not planned", as corepack is never going to leave experimental status in Node.js. It's instead going to be removed from Node.js in v25+ onwards.
On 2024-03-19, the Node.js TSC voted to stop distributing corepack in Node.js v25+
When corepack is installed globally by users using
npm i -g corepack, maintainer confirmed that they don't need to runcorepack enable. This can be documented in README. We need a separate issue for corepack 1.0 release.Reacted by Mike McCreadyReacted by Alexander KachkaevWhen corepack is installed globally by users using
npm i -g corepack, maintainer confirmed that they don't need to runcorepack enable. This can be documented in README.Thanks for your summaries! I've opened
to separately track the documentation issue. I hadn't noticed it before, because every time I installed Corepack with npm I was doing it to test out Corepack and I already had Corepack enabled!
- Adapt installation instructions according to changed distribution strategy #688 suggestion added to pick up some topics from this thread
I can't find any details on the current project status such as anything that needs to be solved before going stable.
corepack enableor will that always be a requirement?