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.

[joyeecheung]

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

[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.

[marco-ippolito]

@nodejs/tsc I'm not sure what are next steps, I'll mention about this at the next TSC meeting

[MikeMcC399]

How would the following voting candidate work?

"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."

In my experience this would be a breaking change. If for instance Corepack is enabled for pnpm, then pnpm can no longer be installed globally via npm. I know this would break my workflows if it were introduced as default in an existing Node.js release line.

For example on Ubuntu 22.04.2 LTS, Node.js 22.14.0 LTS (installed with n), Corepack 0.31.0:

$ corepack enable pnpm
$ npm install pnpm@latest -g
npm error code EEXIST
npm error path /home/mike/n/bin/pnpm
npm error EEXIST: file already exists
npm error File exists: /home/mike/n/bin/pnpm
npm error Remove the existing file and try again, or run npm
npm error with --force to overwrite files recklessly.

[benjamingr]

To reiterate I'm fine with calling for a vote

[marco-ippolito]

cc @nodejs/package-maintenance are we good to proceed with the vote?

[mhdawson]

Based on the discussion in the TSC meeting today:

• Is anybody in the meeting who object or need more time to consider before
  agreeing it can move forward.
  • Nobody in the meeting raised their hand
  • Marco’s plan is to
    • At mention the package maintenance team in the issue
    • Land the PR if there are no objections on Monday

[wesleytodd]

This vote seems to cover all the viable options. Thanks @marco-ippolito for picking this up, and happy to see some movement on this no matter the outcome.

[ljharb]

as a member of @nodejs/package-maintenance

[MikeMcC399]

@marco-ippolito

For the option:

"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."

I understand that would mean that Node.js 24.x would no longer contain Corepack if this option is chosen by voting. For exisiting lines Node.js 18.x, 20.x & 22.x would the version of Corepack be frozen or would you continue to update it during the lifetime of each of the lines?

Perhaps this question is out-of-scope for this vote, however it would need to be answered at some stage if this option is chosen.

[ShogunPanda]

For 18.x, it's going to be EOL in couple of months so I guess it won't be supported anymore very soon.
For 20.x and 22.x I think it will follow the same maintenance we're providing today.

[MikeMcC399]

@ShogunPanda

For 18.x, it's going to be EOL in couple of months so I guess it won't be supported anymore very soon. For 20.x and 22.x I think it will follow the same maintenance we're providing today.

That sounds like a good assumption if everyone voting agrees. (And as you say, Node.js 18 is EOL at end of April 2025, so it doesn't need much consideration.)👍🏻

[mcollina]

lgtm

I think it's time.

One thing: it should be clear that none of the options implies the removal of npm. Right?

[aduh95]

One thing: it should be clear that none of the options implies the removal of npm. Right?

None of the options mentions npm, it’s not the topic of the vote. If you think it should be reworded to be clearer, please send suggestions.

[aduh95]

From last year discussions on Corepack, here are two critics I find fair and unaddressable:

• it is too much limited because it can't manage node versioning (because it depends on node), i.e. if reproducibility is what you're after, Corepack is not enough.
• given npm is going to keep being distributed alongside node for the time being, and npm can download corepack, distributing Corepack ourselves is not worth the maintenance burden.

However, IMO those do not justify getting rid of it, because:

• Corepack users find it very useful to have it distributed with Node.js, so it's not something they need to worry about (a recent incident forced pnpm users to revise that philosophy, and of course there's a non-zero chance that another incident in the future will force users to update independently of node and/or us to release some urgent patch releases).
• If we remove Corepack from the official distribution now, we're leaving users without any easy solution when working on non-npm projects (sure, it's easy for us to say "but they just need to add npx in front of their command" or "they'll have to npm i -g corepack", but let's not forget those come with tradeoffs (e.g. security, FS permissions) that are not always easy to understand for new users).

IMO the best solution would be to replace Corepack without decreasing the current DX, there have been discussions around it – last I heard, the current plan would be to have a builtin "npx-like" (but hum without dependency resolution nor postinstall scripts) that would allow to with a node --run install command to get the ad-hoc versions of node and package manager for the local project on the shell. However, it's been one year, and we can't trust developers who say a feature will be ready soon™, so I suggest we add a few more options that set up a deadline to force things to happen, and give more time for users to adapt. I suggest six months, and keep Corepack on 24.x.

[marco-ippolito]

I guess unbundling gives time to re-think corepack and functionalities. If we decide to unbundle we should do it in 24 since users already have the manual install in their CIs as we can see from npm downloads skyrocketed since breakage and stayed steady if not increasing.

[ovflowd]

Also ✅ as part of package maintenance. + it will not affect the current download website, whatever we decide here.

Although, @nodejs/nodejs-website would like to be notified so we can change "corepack enable" to "npx corepack enable"