Open Corepack Vote

[jasnell]

@nodejs/tsc ... as discussed on this TSC call today. Initiate a formal vote on the corepack discussion

[wesleytodd]

Does the presence of this vote mean the PMWG has a deadline for our goals and corresponding proposal docs? I assume we would want to have a clear picture of our intended future goals before we make changes to the status quo, but maybe y'all are seeing it differently.

[joyeecheung]

The idea is to start a vote but I don’t think we have a timeline for the vote. From the summit some ideas were proposed:

1. Use the next-10 survey coming out this month to test the temperature in users
2. Give the PMWG a few weeks to figure out a short-term strategy

I think for those who are not yet decided, it would be valuable to have more information before they cast their vote. But we should not stall this forever either, so a vote will happen soonish.

[styfle]

Use the next-10 survey

How is the survey distributed?

[wesleytodd]

The idea is to start a vote but I don’t think we have a timeline for the vote

Thanks for the context @joyeecheung! We will work to get that asap. We have good progress happening today here already:

nodejs/package-maintenance#597

How is the survey distributed?

More details here, including us working out the questions we want to ask in this regard. nodejs/next-10#261

[ronag]

Does the presence of this vote mean the PMWG has a deadline for our goals and corresponding proposal docs? I assume we would want to have a clear picture of our intended future goals before we make changes to the status quo, but maybe y'all are seeing it differently.

I don't think this vote affects any potential future goals. IMHO, this vote can happen independently of PMWG's work. I don't see how they are strictly related. Unless the goals of the PMWG match the corepack's implementation exactly.

[GeoffreyBooth]

We have good progress happening today here already

Based on the collab summit and recent discussions, I think we might have consensus that we want to revise https://nodejs.org/en/download to prioritize the application developer use case, recommending installation via a version manager as the default method (see also nodejs/package-maintenance#591).

It would probably be a technical necessity for that version manager to be installed separately from Node, which would mean that the default tab for the download page would be something like a list of instructions where there are separate installation steps for the version manager and then for Node. Once we have that, it follows that the package manager version manager (Corepack) would be one of those installation steps. In this approach, Corepack would be unbundled from Node (and therefore not managed by whatever version manager controls the Node distribution) but still provided for users as part of installation.

[GeoffreyBooth]

Let’s be clear that enabling Yarn and pnpm means creating executables for them.

Suggested change

	- Status Quo: keep distributing `corepack` with Node.js, disabled by default, exactly as it is today.
	- Keep distributing `corepack` with Node.js, enabling `yarn` and `pnpm` by default.
	- Stop distributing `corepack` with Node.js.
	- "Status Quo: keep distributing Corepack with Node.js, disabled by default, exactly as it is today."
	- Keep distributing Corepack with Node.js and include in the Node.js distribution `yarn` and `pnpm` executables that run Corepack to download and run Yarn and pnpm.
	- Stop distributing Corepack with Node.js.

[marco-ippolito]

This should be applied since it's important to make people aware

[aduh95]

Suggested change

	- Status Quo: keep distributing `corepack` with Node.js, disabled by default, exactly as it is today.
	- Keep distributing `corepack` with Node.js, enabling `yarn` and `pnpm` by default.
	- Stop distributing `corepack` with Node.js.
	- "Status Quo: keep distributing Corepack with Node.js, experimental and disabled (i.e. only the `corepack` executable in the distribution), exactly as it is today."
	- "Stable and Disabled: keep distributing Corepack disabled (i.e. only the `corepack` executable in the distribution), and mark it stable in a future release line."
	- "Stable and Enabled: keep distributing Corepack with Node.js, enabled (i.e. `corepack`, `pnpm`, and `yarn` executables in the distribution), and mark it stable in a future release line."
	- "Phase out: stop distributing Corepack (i.e. the distribution will no longer contain a `corepack` executable) on future release lines of Node.js – existing release lines will keep it as experimental."

[joyeecheung]

To avoid giving readers the wrong idea that we are voting to remove corepack from the project...

[joyeecheung]

Suggested change

	prBody: |
	prBody: |
	There are several different visions being worked out about the future distribution
	strategy of package managers and Node.js itself. Some of them involve a bundled
	corepack, some of them need a standalone corepack, some of them do not involve
	corepack. We still have not decided on which vision we want. This vote is
	specifically about whether we should continue bundling corepack before we
	decide on the vision of our distribution strategy. It is separate from whether
	corepack should eventually stay in the organization or be part of the
	future of Node.js, as those are still unclear until we decide about our vision
	in the distribution strategy.

[GeoffreyBooth]

Alternatively we can just decide what vision we want, and presumably based on that this vote won’t be necessary.

[aduh95]

Converting to draft because the tool is not able to handle two open votes at once, and in the last TSC meeting there was consensus about giving more time to the package maintenance team before taking a decision.

[gurgunday]

Did the vote happen? @jasnell

[jasnell]

No, it has not. I'll leave it for someone else to push for.

[marco-ippolito]

Given nodejs/corepack#627 I think we should go for a vote.
Corepack broke and users were able to work around it and most people added npm install -g corepack@latest to their CI.
This is the workaround suggested https://x.com/cramforce/status/1886421427340927152?t=tFcMvSoY9gQiBm5gvl_zTw&s=19.
Users can do that. Having to do a release to fix corepack puts unnecessary stress on releasers. If users can upgrade independently we can ship it outside node bundle. I would like this vote to happen.
The vote should be about removing corepack from the node bundle distribution.

[anonrig]

If users can upgrade independently we can ship it outside node bundle.

@marco-ippolito The same statement can be held for npm, which indeed we updated Node because of a bug in npm even though people could install it directly. In fact we can use the same statement for any dependency (including undici)

[marco-ippolito]

If users can upgrade independently we can ship it outside node bundle.

@marco-ippolito The same statement can be held for npm, which indeed we updated Node because of a bug in npm even though people could install it directly. In fact we can use the same statement for any dependency (including undici)

Corepack is experimental while npm and undici are not. Undici is also bundled and exposes globals so its not possible. Npm is another topic, and I'm open to discuss in another issue😁

[anonrig]

I agree but core pack is only experimental on paper. The usage alone makes the whole thing debatable. @marco-ippolito

[ovflowd]

I agree but core pack is only experimental on paper. The usage alone makes the whole thing debatable. @marco-ippolito

I can almost guarantee that the usage of corepack is probably 0.1% of npm's -- not being in favor of its removal or not. It's just that "usage" and what threshold of usage makes something less experimental or not is a very very unreliable metric.

[marco-ippolito]

I agree but core pack is only experimental on paper. The usage alone makes the whole thing debatable. @marco-ippolito

Then people will vote for it, but we need a vote. I already dont like that we need to do a release for npm which is probably a necessary evil, I don't want the same thing for corepack, and have the maintainance burden. Users have proven they can manage to install it indipendently.

Look at the download stats https://www.npmjs.com/package/corepack
With the breakage users installed it indipendently, we can keep it that way.

[ovflowd]

I agree but core pack is only experimental on paper. The usage alone makes the whole thing debatable. @marco-ippolito

Then people will vote for it, but we need a vote. I already dont like that we need to do a release for npm which is probably a necessary evil, I don't want the same thing for corepack, and have the maintainance burden. Users have proven they can manage to install it indipendently.

Look at the download stats https://www.npmjs.com/package/corepack
With the breackage users installed it indipendently, we can keep it that way.

I like this philosophy

[aduh95]

Users have proven they can manage to install it indipendently.

• The outage did not impact Yarn Berry users (it was triggered by npm registry rotating their private key, and Yarn is self hosted).
• The outage only impacted environments that did not had a working pnpm (or whatever package manager their were using) version in their cache (so mostly CI environment and new users).
• In Newly published versions of package managers distributed from npm cannot be installed due to key id mismatch corepack#612, lots of users have reported updating their Corepack version was not an option for them (and there was a workaround involving env keys, but that wasn't an option either for Netlify users as reported in 22.14.0 'Jod' (LTS) release proposal node#56910 (comment))

I wouldn't take away as "Users have proven they can manage on their own", a portion of Corepack users have been forced into fixing their CI, which I think is quite different.
I would take away that many folks rely on Corepack despite the experimental status, so I agree that something needs to change – but also, whatever we chose to do next, the project must commit to keep maintaining Corepack on the release lines it's been released on, as it's clear that having a broken Corepack has a large ecosystem impact.

[marco-ippolito]

@aduh95 thanks for your detailed feedback. I agree it should be a semver major change.

[MikeMcC399]

The failure of Corepack with pnpm which started on Jan 26, 2025 was quickly corrected in the Jan 27, 2025 Corepack v0.31.0 release. Due to bundling of Corepack into Node.js and other necessary actions of CI providers such as GitHub Actions, there are however significant delays in getting the fix active without user intervention. Node.js 20.x users are having to wait the longest. By the time Node.js 20.x releases an updated bundled Corepack, and GitHub Actions then caches this version in their runners it will be end of March 2025 - a 2 month delay to deliver a fix. Keeping Corepack in Node.js continues this built-in delay for rolling out fixes.

https://npm-stat.com/charts.html?package=corepack shows the impact of users overriding the bundled version of Corepack and replacing it with the version downloaded from the npm registry. Weekly downloads changed from around 200k to 2,000k (factor of 10) after the pnpm issue hit. It seems that users have left the workaround of directly downloading in place, as the numbers are not decreasing at this time.

If Corepack is removed from bundling, then users and CI providers can prepare to install Corepack directly from the npm registry and have more immediate control on the version of Corepack in use, independent of the version of Node.js being used. New Corepack releases with fixed issues can be installed faster. The Node.js Corepack documentation with the label Experimental should also be removed. The current "Experimental" label is being ignored by some users, who are using Corepack in production. Other users take the label seriously and avoid using Corepack, slowing its introduction. The repo's README or an additional separate website should contain all information necessary to install and use Corepack if it is no longer bundled with Node.js.

I lobby for removal of Corepack from bundled Node.js in the interest of Corepack users (current and future).

[marco-ippolito]

I don't want to turn this discussion into another "corepack good corepack bad".
Bundling corepack has proven to have a maintainance burden for an experimental feature. I think it's time to go for a vote and have the TSC decide a final opinion on this matter.
@jasnell I can take over the PR if you are no longer interested, just lmk