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.

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

[joyeecheung]

It seems the discussions about corepack is getting some attention recently. Maybe we should restart the vote, or maybe it's still too early, I am not sure.

To pick up where we were left after the summit #1527 (comment)

This is the Next-10 survey result: https://github.com/nodejs/next-10/blob/main/surveys/2024-04/Node%20Next%2010%20Survey%20Results%20OVERVIEW.pdf

• In "Q13 How do you manage the package manager for your project?", 25.24% respondents chose "I use a tool to pick a specific version per project (e.g. Corepack, asdf, …)"
• In "Q19 Are you using the following experimental features of Node.js?", 28.64% respondents checked corepack

I don't know what's the conclusion in the PMWG, have folks come up with the short-term strategy of corepack as requested in the summit? @wesleytodd

EDIT: I see that the PR in PMWG is nodejs/package-maintenance#606 and folks are also asking about updates there.

[wesleytodd]

Maybe we should restart the vote, or maybe it's still too early, I am not sure.

I think it is too early. That issue is continuing our discussion of next steps. And number 4 of our plan was added as a proposal from the discussion we had in slack, it is not yet reached consensus in the PMWG.

I don't know what's the conclusion in the PMWG, have folks come up with the short-term strategy of corepack as requested in the summit?

Those short term questions are actually was spurred the conversation in slack and this next follow up issue. I would say that we are still in the process of finding a recommendation which has a chance at reaching a consensus. There are a few loose ends which have prevented us from doing more sooner, but c'est la vie.

EDIT: Our meeting is in ~30min, please come and discuss.

[anonrig]

@wesleytodd Number 4 already makes the decision and makes this voting obsolete. Am I missing something?

[wesleytodd]

I replied in the conversation over there. That discussion is to produce a recommendation, it is not a decision itself. In fact we discussed locking these other issues temporarily to focus the discussion and reduce the spammy noise from the other threads until we have a recommendation with consensus from the PMWG, as agreed upon by the TSC in a former meeting.

If folks agree with the recommendation to temporarily lock all the related issues across the other repos, then I would suggest we start with this one for now. The goal is not to silence anyone, just to help keep the conversation focused and productive, and having it in many threads all at once does not help.

EDIT: it looks like @ovflowd already did have to in nodejs/node#51981 (comment), and I think this is the right move for now. So idk who would need to take this action but I do not have all the proper permissions to do it.

[benjamingr]

If folks agree with the recommendation to temporarily lock all the related issues across the other repos, then I would suggest we start with this one for now. The goal is not to silence anyone, just to help keep the conversation focused and productive, and having it in many threads all at once does not help.

This issue has not had external/problematic activity recently. Locking issues is a measure we take to prevent spam (typically from outside collaborators) and cool off heated discussions.

Before Yagiz's comment today there were 3 weeks of inactivity and Yagiz mostly just asked for the status. I'm not sure what locking it benefits us?

[wesleytodd]

Yeah I totally agree this one has not been an issue. Those other ones were the target of our initial recommendation. This one just was the first one in my notifications inbox so it is where I commented it. As long as this one is not at risk of spiraling I am fine keeping it as it.