Node.js TSC Confirms: No Intention to Remove npm from Distribution

The Node.js Technical Steering Committee (TSC) met this week and made a few key decisions as part of the broader discussion regarding enabling Corepack by default. Members in attendance confirmed they have reached a consensus that there’s no intention to remove npm.

The discussions surrounding Corepack had previously raised the question of whether npm would be provided through Corepack moving forward, as some contributors hold the opinion that removing npm from the Node.js distribution is the eventual goal of integrating Corepack.

A PR, opened by TSC member Geoffrey Booth, was merged last week, codifying this consensus. It states that removing npm is not an objective for the project:

As part of resolving the request of the members of the TSC who met on 2024-01-24, this PR aims to help clarify the goals of Corepack. In particular, this clarifies that it is a non-goal of Node.js overall, and therefore Corepack by inclusion, to work toward removing npm from the Node.js distribution.

This also codifies what was written in #50963 (comment), which seems to be a consensus:

1. we solidify the “special relationship” with the npm client, clearly stating that it’s vendored because it is the reference implementation for the npm registry, as well for historical reasons.

The PR updates Node.js’ Technical Priorities document with a new Package Management section:

The ability to easily install and manage dependencies and development tools is a key part of the user experience, and for that reason Node.js must provide a package manager as part of its distribution. Node.js includes npm for this purpose. This is for historical reasons — when npm was added in 2011, it was the only JavaScript package manager — and because it is the reference implementation for the npm registry, which is the de facto primary source for most JavaScript software. In accordance with our policy of not including multiple dependencies or tools that serve the same purpose, the Node.js project does not include any other package managers; though it may include other software to download other package managers.

This PR follows a meeting of the TSC on January 24, 2024, which sought to clarify the aims of Corepack within the Node.js ecosystem. It confirms that regardless of what ideas are discussed in pursuit of enabling Corepack, removing npm is not a goal of the Node.js project.

TSC members represent diverse opinions and interests, and this PR was not without a small amount of pushback.

“I'm -1. Unbundling npm should be a goal for the long term,” TSC member Yagiz Nizipli said.

Ultimately, the majority of members were in favor of taking the issue of unbundling npm off the table.

TSC member Myles Borins, speaking on behalf of npm, urged contributors to consider the question - “Should Node.js ship with a package manager” - from a practical standpoint. He also encouraged participants in the discussion to put aside rhetoric and work to build consensus around the architectural decision:

If possible, I'd also really like to stop the debate around unbundling npm or not. I recognize my bias and conflict of interest here. To be clear, I think making the statement on its own is problematic as it over simplifies a complex problem space. Let's be clear about the goal and why. Simply unbundling npm makes Node.js worse without a clear solution in place to replace it. If the goal is to "only dynamically fetch package managers" or "distribute all package managers via corepack" it feels a lot less targeted. Simply saying "our goal is to unbundle npm" comes across extremely hostile to a team of developers who do a lot to support the Node.js project and JavaScript ecosystem, independent of corporate affiliation. If your goal is instead "only independently or neutrally maintained package managers" call that out, up until this point nothing of the sort has explicitly been said. Let's have goals and solutions not problems and othering.

Booth landed another PR recently, adding a Node.js Distribution Policy document, which states that the project “includes some external software that the Node.js project does not maintain.” It also reaffirms the project’s support of competition in the JavaScript ecosystem:

The choice to include a particular piece of software should not imply anything about that software relative to its competitors; in some cases, software was added when it had no competitors. While the Node.js project supports and encourages competition in the JavaScript ecosystem, as a policy, the Node.js project does not include multiple dependencies or tools that serve the same purpose.

This PR is aimed at focusing the decision-making around Corepack, removing some of the unknowns, and documenting the consensus emerging in the various Corepack-related threads.

Next Up for Discussion: Placeholder Executables#

During this week’s meeting, TSC members made some progress on discussions regarding enabling Corepack by default but agreed there is no need to rush the decision for Node.js 22.

Contributors are currently discussing a policy for “placeholder” executables, considering whether Node.js will install links that enable binaries, scripts, etc. outside of Node.js. One of the questions is whether placeholders puts Node on the hook for any security issues contained within the placeholder.

“Even if we have some fine print somewhere saying that somehow we’re not responsible for any vulnerabilities within the Yarn software that our yarn command downloads and installs, I think many users would understandably argue that that doesn’t absolve us: that we should provide the same security guarantees for Yarn that we do for npm, even if Yarn isn’t actually bundled within our distribution,” Booth said in the PR.

Booth also contends that it would complicate compatibility and update policies, as major updates to the executable would have to align with Node’s schedule, reducing flexibility and possibly delaying updates. Additionally, placeholders locked to specific versions or to the latest version within a major version line could lead to a poorer user experience compared to existing installation methods.

Booth argues that placeholder executables also serve an unnecessary “political” purpose and imply a recommendation of the software:

Just as bundling npm arguably implies a recommendation of npm, shipping placeholders implies equivalent recommendations for those other tools. Obviously this is desirable for competitors to npm, but I don’t think this is a road we as a project want to go down: it’s much easier to state that we’re agnostic and don’t have recommendations for any tools, rather than having debates about every tool that someone proposes to create a placeholder for.

Booth’s PR recommends the project draw a line in the sand and states that Node.js will not create placeholder executables (commands that refer to software that is not distributed with Node.js but instead are downloaded when the command is run.)

The TSC intends to have more discussion on placeholder executables next week as part of the Corepack decisions. During this week's meeting, Booth encouraged participants not to nitpick the wording too much but rather to move towards a decision on whether Node.js will allow placeholders or allow them just for package managers. If allowed, does Node.js have to take responsibility for them? What will it cost the project? There are multiple ways this decision could go.

The Corepack discussion is ongoing. Landing on a decision regarding placeholder executables will put the TSC in a better position to address open PRs regarding enabling yarn and pnpm Corepack binaries by default and the proposal for an alternative to enabling Corepack by default.