Project Status (experimental to stable?)

[styfle]

I can't find any details on the current project status such as anything that needs to be solved before going stable.

1. Are there any outstanding blockers?
2. Are there known breaking changes coming up?
3. Do we need to get npm working to be considered stable?
4. Will a stable release remove the need to run corepack enable or will that always be a requirement?

[andersk]

I’d hope for security that corepack starts checking integrity hashes before it’s enabled by default.

• Allow checking hashes for exact versions, and check them for default versions #37

(Edit: This was briefly fixed, but it was then reversed by #134 and remains a problem.)

[trivikr]

Visiting 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.0 in 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#3591

I think we should revive this GitHub issue after yarn v4 release.

[arcanis]

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 enable won't be needed.

[styfle]

I'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@latest in 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 dev will shell out to npm or npx and corepack being enabled could block it from working properly.

Update: I created #157

[styfle]

Checking 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 install in a minor version (8.6.0) suddenly causing builds to fail, and corepack allowed users to continue using the old behavior

That being said, the one thing missing today is default support for npm when I run corepack enable. However, corepack enable npm is 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.

[aduh95]

Checking 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 install in a minor version (8.6.0) suddenly causing builds to fail, and corepack allowed users to continue using the old behavior

That'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 npm is 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.

[styfle]

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.4 has signed releases either?

Unless the { "packageManager": "pnpm@7.13.4" } config doesn't pull from the npm registry like I expected? 🤔

[aduh95]

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.4 has 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?

[styfle]

This issue needs to be fixed before going stable:

• Use the package manager version specified by the project, but still allow other package manager invocations #195

[yarinsa]

@styfle What prevents corepack to be stable in Node20?

[arcanis]

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.