Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open Corepack Vote #1527

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Open Corepack Vote #1527

wants to merge 3 commits into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Apr 10, 2024

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

@github-actions github-actions bot changed the base branch from main to initiateNewVote April 10, 2024 17:05
@jasnell jasnell requested a review from a team April 10, 2024 17:05
@wesleytodd
Copy link
Member

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
Copy link
Member

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
Copy link
Member

styfle commented Apr 10, 2024

Use the next-10 survey

How is the survey distributed?

@wesleytodd
Copy link
Member

wesleytodd commented Apr 10, 2024

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
Copy link
Member

ronag commented Apr 10, 2024

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
Copy link
Member

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.

@jasnell jasnell requested a review from aduh95 April 10, 2024 21:48
Comment on lines +27 to +29
- 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

The objective of the vote is to determine a basic question: do we continue bundling
the corepack binary with Node.js or not, and if so, do we enable bundling jumper
binaries for its supported package managers (such as yarn and pnpm) by default or not.
There are additional questions to resolve that will be handled separately.

# 6. Optionally, insert a brief introduction for the vote PR, in the markdown format.
prBody: |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@aduh95 aduh95 changed the base branch from initiateNewVote to main April 23, 2024 18:31
@aduh95 aduh95 marked this pull request as draft April 23, 2024 18:32
@aduh95
Copy link
Contributor

aduh95 commented Apr 23, 2024

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
Copy link
Member

joyeecheung commented Jul 30, 2024

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
Copy link
Member

wesleytodd commented Jul 30, 2024

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
Copy link
Member

anonrig commented Aug 18, 2024

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

@wesleytodd
Copy link
Member

wesleytodd commented Aug 19, 2024

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
Copy link
Member

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
Copy link
Member

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.

@Akiyamka

This comment has been minimized.

@diraneyya

This comment has been minimized.

@joyeecheung

This comment has been minimized.

@ovflowd

This comment has been minimized.

@diraneyya

This comment has been minimized.

@ovflowd

This comment has been minimized.

@ovflowd

This comment has been minimized.

@ovflowd

This comment has been minimized.

@diraneyya

This comment was marked as off-topic.

@ovflowd

This comment was marked as off-topic.

@aduh95

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.