node
node copied to clipboard
nodejs
deps: remove corepack
"Package managers" manage packages & their versions. Package managers are packages themselves. This makes a "package manager version manager" redundant. Improvements can be made to the existing default tooling (ex. devEngines).
Users can still access Corepack via npm, npx (ex. npm i -g corepack or npx corepack) or source as they were prior to #39608.
Fixes: https://github.com/nodejs/node/issues/51888 Related to: https://github.com/nodejs/node/pull/51951
@nodejs/tsc @nodejs/corepack @nodejs/npm @nodejs/package-maintenance
Review requested:
- [ ] @nodejs/actions
- [ ] @nodejs/security-wg
- [ ] @nodejs/startup
- [ ] @nodejs/tsc
I don't think this is feasible, as there is massive user support behind having yarn and pnpm binaries.
However, I think you could implement the proposal in https://github.com/nodejs/node/issues/51931, which would solve have the same user need without corepack.
Isn't it possible to install both yarn and pnpn with npm?
Corepack doesn't only exist to install yarn and pnpm. It manages multiple installed versions and ensures the right one is used based on the current project.
Isn't it possible to install both yarn and pnpm with npm?
One command in a bash script/Dockerfile/instruction is too hard/burdensome for many users.
Corepack doesn't only exist to install yarn and pnpm. It manages multiple installed versions and ensures the right one is used based on the current project.
The perceived value for users is that it allows them to use yarn and pnpm without a specific install command. They are mostly oblivious to the problems of "multiple installed versions" and how to manage this safely.
One command in a bash script/Dockerfile/instruction is too hard/burdensome for many users.
So these users are sophisticated enough to use a package manager but too novice to install a package manager?
I think I agree with what @mcollina meant, but I don't really agree with the phrasing in https://github.com/nodejs/node/pull/51981#issuecomment-1980602081.
IMO, it's more useful to think about the "least friction path":
- without Corepack in the Node.js distribution, the path of least friction is to use a globally managed version of your package manager (either the provided
npmbinary, but another package manager installed by e.g.npm i -g yarn). - with Corepack in the Node.js distribution, the path of least friction (for non-npm project at least) is to pin package manager per project, effectively treating the package manager as a dev dependency. (And even more so since https://github.com/nodejs/corepack/pull/413 landed.)
Of course, whether treating a package manager as a dependency is desirable is up for debate (but let's try not to do that in this thread to keep the conversation about the proposed change), but from what I heard it's one reason that Corepack users have found compelling; and personally, I think the whole ecosystem would benefit from that pattern being more wide-spread (for the same reasons lock files were a good thing for the ecosystem).
Also, it does reduce some friction for users of Yarn and pnpm, which is also a positive IMO. (I reckon that point is debatable, but at least for Yarn Berry users it's pretty clear the UX is better with Corepack).
Certainly Corepack is not strictly necessary to achieve what its users are doing with it, it's not the only tool that can do it, and it's far from perfect. However Corepack users are still getting value out of it, and certainly it would not have gotten the same interest if it wasn't maintained within the project and distributed with Node.js.
TL;DR Having Corepack removes some friction for some of our users. Removing it adds friction, I don't think we should do that.
~I'm -1 here as well.~
Not applicable anymore. See https://github.com/nodejs/node/pull/51981#issuecomment-2016365997
Having Corepack removes some friction for some of our users. Removing it adds friction, I don’t think we should do that.
I don’t think this is really in dispute; the question is whether the reduced friction is worth the cost. We could bundle CoffeeScript, too, and that would also reduce friction for some of our users. We could bundle any number of things, some of which might arguably be more useful or serve more users; I think the general rules of what should go into core should apply to what goes into the bundle. Arguably those rules should mean we exclude npm, but npm got included long before those rules were written; and besides, each addition should be judged on its own merits.
I think the DX is a good idea and wouldn't mind pursuing it. But this corepack question is taking too much effort.
I think there already are alternatives (though maybe not as user friendly)
You can install corepack:
npx corepack or npm i -g corepack
You can install a package manager
npm i -g yarn or npx yarn
You can pin a package manager version to your project.
npm i yarn@{version} npm run yarn {command}
@mcollina since it is experimental I believe breaking it by saying "now you need to install it first" is reasonable. Do you think being used while experimental should be a blocker to removal in general or for this one specifically?
Additionally, if we could propose a viable alternative with a future path toward replacing the UX, would that help change your mind?
Do you think being used while experimental should be a blocker to removal in general or for this one specifically?
If this is the case, we should revisit what experimental means and keep that in mind when adding things as experimental.
if we could propose a viable alternative with a future path toward replacing the UX, would that help change your mind?
This is what I meant. Corepack fits a use case, and I don't think we should remove this without filling it with something else.
I don’t think we should remove this without filling it with something else.
All this PR does is change how users get Corepack: instead of running corepack enable they’d run npm install -g corepack. It may be removed from the Node bundle, but Corepack isn’t getting deleted or abandoned. It can continue to flourish as an independent project, and users can continue to use it.
Corepack doesn’t depend on anything in core, so it doesn’t benefit from being bundled with core. (It would’ve needed to be part of core for us to remove npm, but we took that goal off the table.) I think it’s likely that any future replacement for Corepack would also not need to be bundled into core, so there’s not much reason to keep Corepack in core until that replacement comes. It’s arguably better to have neither solution in core: then users can choose which one they prefer, and benefit from the competition.
@GeoffreyBooth All of those things can be said of fetch as well, yet I don’t think we should remove fetch from core.
@GeoffreyBooth All of those things can be said of fetch as well, yet I don’t think we should remove fetch from core.
fetch was added because of the web api which we have goal to support as well as possible. Totally different ballgame.
It's unclear to me what anyone would gain from this PR.
It would move the question off the table so that we can focus on other things.
Another option is to keep the status-quo (i.e. corepack not enabled by default but bundled) indefinitely. The risk is that then this endless discussion keeps festering and collaborators continue getting either exhausted or frustrated.
I'm sorry if my contributions are a bother to you, but maybe a more effective way to move the focus would be to enforce the 2021 TSC decision and let folks who want to work on this problem make some progress. It seems there's a lack of trust towards the Corepack team and the package maintenance team to build consensus, which is quite bothering to see tbh.
Corepack isn’t getting deleted or abandoned
How do you know? Are you planing on maintaining it? If not, don't make promises you don't intend to keep.
I'm sorry if my contributions are a bother to you,
You are misrepresenting. What bothers me is our lack of progress on this issue despite the effort we have put into it. What also bothers me is the TSC's difficulty in making decisions in general and the impact this has on the project (we are all getting frustrated with each other).
It would move the question off the table so that we can focus on other things.
There are actual people using Corepack everyday because they really like it, and they deserve better than "let's kill this off to please X".
There are actual people using Corepack everyday because they really like it
This is the important part of the previous message, and as I said before I do not think we should remove this without an alternative.
I do not think we should remove this without an alternative.
The alternative is that people install Corepack directly instead of it already being included in the Node distribution. We don't need to create some new thing first. Corepack is fine and can continue to exist on its own. It is useful, but its use cases that I can guess at seem pretty distant from the use cases we're trying to support by Node, so it should live on its own—which is fine—and the same would be true of any potential replacement.
Arguing that an alternative needs to be in core implies that there's some use case or goal that Corepack satisfies that the alternative would also need to satisfy. What is that use case? Is it something we have consensus on?
How do you know? Are you planing on maintaining it? If not, don't make promises you don't intend to keep.
I was speaking about this PR. This PR doesn't delete Corepack in general; Corepack lives in its own repo and is published to the npm registry, because it's its own project and will remain so after this PR.
People are choosing Corepack because it shipped with Node.js and because it defines a canonical way to define your package manager.
This is why I chose to add support for Corepack to Vercel and all of Vercel's customers.
Removing it from Node.js core will surely decrease adoption and potentially kill Corepack.
Update: Added a poll: https://twitter.com/styfle/status/1772353395321454916
it defines a canonical way to define your package manager nodejs.org/api/corepack.html
But it doesn’t, really, since npm doesn’t support the field. #51888. And standardizing package.json fields isn’t part of the Node project’s scope; https://github.com/openjs-foundation/package-metadata-interoperability-collab-space exists for that, and there’s https://github.com/openjs-foundation/package-metadata-interoperability-collab-space/issues/15 specifically for this. Maybe Corepack and npm and other package managers can reach an agreement and standardize, which would be great, but it doesn’t follow from that that Node must therefore bundle Corepack (or anything else).
@mcollina Here’s a potential alternative. We update https://nodejs.org/en/download to recommend installing Node via a version manager; and we also recommend version managers that include managing both the runtime and the package managers (or two tools for managing the two things). We would still provide the full list of options that we do now, but the version management approaches would be shown first, possibly even with some text like “Node.js recommends” to push people toward version management installations rather than downloading binaries. Corepack would be one of the recommended options, similar to https://pnpm.io/installation. And so no version management solution would be included with Node, it would be part of how the user installs Node and package managers. And not bundling any particular solution means that users have more options to choose from.
People are choosing Corepack because it shipped with Node.js and because it defines a canonical way to define your package manager.
Sure, except it's never been a supported way to choose npm? This is pretty well documented so I don't feel like I need to go into why, but the current most used package manager not having a good path in that feels like exceptionally bad DX that will not lead to anywhere except where we currently are.
Update: Added a poll: https://twitter.com/styfle/status/1772353395321454916
Please don't use Twitter Polls as a meaningful indicator of the JavaScript ecosystem's stance on things. We're going to get a deeply biased response, especially with how deeply unsafe that platform has become.
I feel like I'm missing something. Isn't the only thing this PR changes is how you enable/install corepack from one command (corepack enable) that you need to figure out from the documentation to another command (npm -g corepack) that we can add to the documentation? From the user's perspective I don't see how this can be significant.
EDIT: From what I've understood is that the concerns with this PR is mostly related to the politics/feelings of "demoting" corepack than any technical or user experience issue (which makes both @anonrig's and @mcollina's objections confusing for me). I'm not sure how I feel about that.
EDIT2: Another reason for objection (I guess) is that it's unnecessary to remove corepack if we are going to enable it by default in the future anyway. Though again, not sure whether this PR makes much difference in that regard.
Sure, except it's never been a supported way to choose npm? This is pretty well documented so I don't feel like I need to go into why, but the current most used package manager not having a good path in that feels like exceptionally bad DX that will not lead to anywhere except where we currently are.
Different projects have different DevX; the DevX choices made by the Yarn team have no impact on the npm team, and vice versa. If you want npm to be distributed primarily through Corepack you're free to open a feature request on their repository and lobby them, but I don't see that as a reason to deprive other package managers from a tool useful to their users.
From the user's perspective I don't see how this can be significant
It's a breaking change, and it clearly signals that Corepack will never be enabled by default, which is not the intended end state (don't forget that this all started from an issue from one of your users asking for Corepack to be enabled by default).
A third reason is that such moves can erode some of the trust that users have in the project. That's not specific to Node.js, it's just how open-source projects work in general. End users who started using Corepack to manage their package managers and sold it to their teams because it was supported by Node.js won't forget if the carpet is pulled from under them, which may make it harder for them to trust what you ship.
Can they trust require(esm) to eventually be unflagged, or is there a chance it'll get removed if someone has an ideological issues with it? Same with fs.glob, can it be used in our scripts, or should we expect it to be removed altogether? And none of those two features had a TSC vote requesting them, or had been distributed for the past two years.
From what I've understood is that the concerns with this PR is mostly related to the politics/feelings of "demoting" corepack than any technical or user experience issue
I think it's rather the other way around: this PR is obviously about politics and completely ignore the opinion of the pnpm team, the Yarn team, the Node.js TSC, the impacted users, and of course the Corepack team. It doesn't engage in a constructive way, and handwaves away users already using the feature.
Tbh in any other project I'd have seen such PRs as trolls; attempting to rollback changes made by contributor X without their approval, or adding in the project core documents that "we promise to never do the very thing contributor X is working on" by pretexting the status quo, all that feels grotesque to me.