-
Notifications
You must be signed in to change notification settings - Fork 127
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
base: main
Are you sure you want to change the base?
Open Corepack Vote #1527
Conversation
Co-authored-by: Ruy Adorno <ruyadorno@google.com>
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. |
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:
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. |
How is the survey distributed? |
Thanks for the context @joyeecheung! We will work to get that asap. We have good progress happening today here already: nodejs/package-maintenance#597
More details here, including us working out the questions we want to ask in this regard. nodejs/next-10#261 |
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. |
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. |
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
- 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. |
There was a problem hiding this comment.
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.
- 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. |
There was a problem hiding this 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: | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
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.
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. |
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
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. |
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.
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. |
@wesleytodd Number 4 already makes the decision and makes this voting obsolete. Am I missing something? |
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. |
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? |
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. |
@nodejs/tsc ... as discussed on this TSC call today. Initiate a formal vote on the corepack discussion