Node.js Community Debate Intensifies Over Enabling Corepack by Default and Potentially Unbundling npm

A heated debate is happening in the Node.js community over a proposal to enable Corepack by default that was opened in November 2023. This sparked the question of whether npm would be provided through Corepack moving forward, as some contributors hold the opinion that the eventual goal of its integration is to uncouple Node.js releases and npm releases.

Corepack allows developers to use Yarn, npm, and pnpm without having to install them. Although Corepack is already distributed by default with all recent Node.js versions, developers still have to run corepack enable to install the required Yarn and pnpm binaries.

Proponents of enabling Corepack contend that it would streamline the development experience by simplifying version management for package managers. They also argue that enabling Corepack by default would offer a more level playing field for alternative package managers, potentially shifting the landscape away from npm's current dominance and allowing other package managers to gain wider adoption.

npm Firmly Opposes Distribution Through Corepack#

Myles Borins, commenting on behalf of npm, stated in no uncertain terms that npm opposes distribution through Corepack:

I support unflagging corepack and any package manager that wants to integrate. npm does not wish to integrate for a variety of reasons and we don't want to be forced into supporting this pattern.

I wouldn't block any work to enable corepack by default in Node.js for other package managers, but I do object to it being used for npm, and for any sort of npm support being on by default. My request would be that if corepack is enabled by default that npm support remain behind an additional flag or command that would be opt-in for developers. If developers want a flow that includes corepack I personally think they should choose a different package manager developed and designed to use this pattern such as yarn. This is the beauty of having an ecosystem of tools, and I don't think that npm should be forced to use a pattern it is not designed to utilize.

Borins also cited a number of technical issues with Corepack distributing npm, which he elaborated on in a detailed comment:

• The jumper pattern introduces extra indirection / lack of clarity as to what version of the package manager is being used and where on disk
• Pinning the package manager at a project level can lead to exposure to security vulnerability
• Lack of clear testing of node + package manager version to update package manager versions
• A hard coded version for package managers in Corepack adding additional labor to updating
• Must dynamically install the package manager over the network to get started
• Lack of clear benefit to npm while creating additional work

If enabling Corepack by default changes how npm in distributed with Node.js, this change would defy the wishes of the npm team by introducing what Borins contends is “more complexity and inconsistency without significantly improving the status quo.”

Node.js Technical Steering Committee Discusses Enabling Corepack as a Path to Removing npm from the Node.js Binary#

During the Node.js Technical Steering Committee (TSC) meeting on January 10, TSC members discussed the issue at length but did not have clarity on the goals of the proposal.

The question remains whether it even makes sense to add Corepack if the goal isn’t to remove npm from the Node.js binary. Is the primary motivation to enable Corepack as a way to address the perceived unfairness about npm’s historical preeminence in being bundled by default? Or is the objective to improve the developer experience for those using less popular package managers?

TSC member Yagiz Nizipli, one of the more vocal proponents of unbundling npm from Node.js, recommended the committee move to either remove npm or bundle additional package managers. He suggested that the ambiguity about this situation is creating unnecessary friction.

Nizipli contends that Node.js should be concerned with bundle size and consider the strategic advantage of npm over other package managers. He is unhappy with users being forced to install npm in order to install and use alternative package managers. Without enabling Corepack, there is no path to removing npm as a dependency of the Node.js binary.

npm's Role in the Node Ecosystem's Unprecedented Success#

Other TSC members contend that npm shipping with Node.js is a critical part of the success of the ecosystem.

Matteo Collina, in attendance at the meeting, said that shipping a package manager by default is one of the key factors for Node flourishing and he doesn’t see a good technical reason to migrate npm out. One of the main advantages of shipping npm is the stability of the build.

“If you install a Node version, you have absolute clarity on the version of npm you’re going to get and you can have a clear build,” Collina said. “If you use Corepack you don’t and people don’t have a clear build. This is a time bomb for maintainers in the ecosystem.”

Collina suggested the least contentious way forward would be to enable Corepack and remove npm support from Corepack, so the npm team is not forced to distribute the package manager through what they deem to be a technically objectionable method. He also recommended separating out the topic of unbundling npm.

Others in attendance at the meeting do not believe it’s possible to remove npm without introducing massive breaking changes and creating a mountain of frustrated users.

Another consideration TSC members raised is whether Corepack is widely used enough to support the Node ecosystem - do developers even know what it is? The committee agreed they do not yet have a full understanding of the impact of this proposed change and anticipate that it could be severely disruptive.

Unbundling npm Is Too Contentious to Reach a Consensus: TSC Will Put It to a Vote#

In most cases for internal project decisions, the TSC operates under a Consensus Seeking decision making model. In this case, the committee agreed that the matter is too contentious and opinions too diverse for them to be able to reach a consensus. No amount of discussion will lead to an obvious solution. They agreed that it should be put to a vote to determine their answers to the following questions:

• We agree our goal is to remove npm from Node.js: Yes/No
• If we are not going to remove npm, should corepack be included in Node.js Yes/No
• Should we enable corepack by default today: Yes/No

TSC member Geoffrey Booth suggested whoever wants to champion removing npm should write a separate proposal before putting anything to a vote. He said the matter is not urgent and anticipates that the earliest anything would happen is April 2024. The topic hasn’t been on the agenda for the last few meetings.

Two weeks ago, Booth suggested that interested stakeholders organize their thoughts in PRs addressing what Node.js’ technical priorities should be in regards to bundled package managers:

I don’t think the Corepack question is ripe for the TSC to discuss again just yet. Multiple people on that thread have advocated for starting new threads to try to reach consensus on the various open questions; I suggested opening PRs against https://github.com/nodejs/node/blob/main/doc/contributing/technical-priorities.md to try to establish what goals we’re intending to achieve, before we move on to the second question of choosing the best way to achieve them. I was thinking that those PRs could be one way to organize the discussions that we need to have; or people can just open new issues that are more scoped than the current one. Regardless, there are many, many open questions and I don’t think this is anywhere close to being ready for the TSC to make any decisions.

Meanwhile, the discussion continues on GitHub and the original issue has 100 comments from people invested in the outcome.

“I 100% support anything we can do to make client access easier, to reduce steps to getting started, to making the experience better, and to leveling the playing field,” Borins commented on the thread. “I do not support forcing the adoption of Corepack to teams that do not want to use it.” He reiterated his position, speaking on behalf of npm:

• Let's ship pnpm + yarn in the way they want to be consumed
• Let's unflag corepack if that is the way to do it
• Please don't force npm to use corepack
• Please separate the discussion if you want to dig in to unbundled npm

Ultimately, the Node.js Technical Steering Committee will make the decision following more exploration and discussion. If Corepack usage proves to be as meager as some suspect, would the committee have the temerity to enable it by default and unbundle npm against the team’s wishes? This seems unlikely but it is still a topic of discussion.

“I don't think vendoring Yarn and PNPM into Node.js like npm is a realistic option (more security issues, more bundle size, and would likely not fit well with our LTS policy),” Node.js collaborator Antoine du Hamel commented.

“I also don't think it would make much sense to discuss unbundling npm because of the ecosystem impact. If the Release Team wants that to happen (I think they are the ones who are the more likely to be affected by that decision), we could discuss it, but that doesn't seem very productive to go this route. (It'd be like Node.js and npm calling each other's bluffs until one project caves, or everyone loses)."

Why Node.js Ships with a Package Manager Included#

npm inventor and founder Isaac Schlueter joined the discussion on GitHub, offering some historical context on why Node.js ships with a package manager:

Despite conspiracy theories I've seen claiming otherwise, there was no shady back room deal to get npm bundled with node. Ryan and I saw that users were constantly thwarted at the point of trying to get a node project up and running, and couldn't do much without a package manager, so we started shipping npm along with node. There wasn't any other alternative at the time, and it was the one supported by a member of the core node team, so it was the obvious choice. It was discussed in the open, and not controversial; people needed it, so we gave it to them, that was that.

He does not think that a level playing field for package managers should be Node's concern and encouraged the community to examine whether Corepack is the best solution to Node’s problems.

“Different OSS projects get different levels of exposure and distribution, so what?” Schlueter said. “This seems like very much not node's problem. Node should care about the experience of node users and their success using node, not whether any given package manager has a ‘fair’ portion of the ‘market’ (a ‘market’ in which no one pays and the ‘winner’ is rewarded with nothing but costs). Should Node include an alternative JS engine or TLS implementation, because it ‘unfairly’ privileges V8 and OpenSSL? ‘Fairness’ is an absurd criteria for a question like this.”

It’s Time for Node to Formalize Its Relationship with Package Managers#

Any major changes to the status quo will need to be heavily substantiated, as the long-term impact on the Node.js ecosystem and development workflow could be forever altered in a way that may not foster the same level of innovation and community engagement. At this level of maturity as a project, it’s time for Node.js to formalize its relationship with package managers in a clear way that is rooted in its technical priorities.

“Beyond that, even in this thread the question which is at the crux of it is being punted on: What should the formal relationship between Node.js and the various additional tools required to build and run a project be?” Wes Todd commented. “When folks ask what requirements should be met to be a tool included in Corepack, or how it will be vetted and decided, there is not a clear answer."

These are important questions to answer before altering the future of JavaScript package managers. As the Node community continues to wrestle with these hot topics of debate, Todd encouraged participants in the discussion to recognize the gift npm has been to the ecosystem.

“Yes I get that npm has a contentious place in this as it was bundled before it was ever a for profit entity, yes I understand that it is fundamentally problematic that the registry where we all publish and install from is part of that deal.

“That doesn’t change the fact that we are all here today with one of the largest software platforms and audiences in the world because of those folks’ work. Even with the bumps in the road the folks who have worked on npm have given this ecosystem a gift and taken care of their responsibility better than most of us could if we had to. Now is the time to put aside that history and discuss what is best for Node.js, its maintainers, its users, and the JS ecosystem at large.”