globally installing npm should not be the recommended way for Mac and Linux

[mcollina]

Most people that use Node.js will have problems if they install Node.js globally, because they would require npm to install libraries globally with sudo. This got 1503 upvotes on StackOverflow. This is the page on how to fix the npm permission issue: https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally. This is scary for most newbies, and they will have to go through.

Note that npm recommends to use a version manager as the best way to install Node.js: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm. I agree with them, it's the safest and mo way to install Node.js.

The list of things that creates this kind of permission issues for our users:

1. distro-specific packages (deb, rpm, brew, port, ...)
2. dmg file for Mac OS X

I've personally fixed 100+ computers with this problem across my life. Fixing this requires some not-so-nice solution like sudo chown -R $(whoami) ~/.npm.

Another technical solution that is not nvm can be found.

[davidfekke]

I agree with Matteo. There needs to be a default package manager when you install Node.js. Removing it would create a horrible DX.

[ovflowd]

cc @nodejs/tsc I'm in agreement here, and in favour of marking Package Manager as the default tab. Please let us know if there's any 👎 with reaction to this comment, otherwise we'll proceed with a PR.

[tniessen]

Personally, I consistently use nvm (in dev environments!). On Windows, I am not sure what a good fit is. Does the Windows installer also regularly result in permission issues?

[ovflowd]

Personally, I consistently use nvm (in dev environments!). On Windows, I am not sure what a good fit is. Does the Windows installer also regularly result in permission issues?

FYI this issue is about making the package managers (ie NVM) the default tab... (I might have misunderstood your comment)

[tniessen]

Sorry, I am a bit confused. Is this about the website redesign or about the current production website?

[ovflowd]

Sorry, I am a bit confused. Is this about the website redesign or about the current production website?

Redesign!

[ovflowd]

(On the last TSC meeting, @mcollina raised the concern of package managers should be the default way instead of using installers, and then Ive asked him to open an issue after the meeting)

[richardlau]

Personally, I consistently use nvm (in dev environments!). On Windows, I am not sure what a good fit is. Does the Windows installer also regularly result in permission issues?

I haven't used it in a while but it should not do as on Windows npm install -g goes into AppData\Roaming (e.g. \Users\{username}\AppData\Roaming\npm).

[mcollina]

Windows installer is ok.

[mhdawson]

Transferred to the package maintenance repo as agreed in the TSC meeting today.

[wesleytodd]

Just wanted to drop an update. @aduh95 and I have been discussing an proposal for this group to take on more official governance of this scope and he has a draft. Hopefully today/this weekend we can get it into shape. Honestly it is me holding it up, I had planned on doing it after last PMWG meeting but have been distracted.

[GeoffreyBooth]

Just thought I’d relay part of nodejs/node#51981 (comment) here:

@mcollina Here’s a potential alternative. We update 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 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.

I think we publish binaries both with and without Corepack, right? Do we (or could we) publish binaries both with and without npm?

Because then the install instructions can be a bit more of a “choose your preference”. Like, we recommend installing Node via a version manager, and we also recommend installing your package manager via a version manager. If you want to take our advice, here are some version managers you can use; and here’s how to install Node via them, and various package managers via them.

And if they want to use version managers for both the runtime and for the package manager, then it makes sense that the runtime would be the no-npm, no-Corepack binary. Then the package manager version manager could be fully in control of all package managers on the system, including npm.

This is kind of the best of both worlds: the folks agitating to get npm out of our distribution would have a way to install Node without npm, while at the same time users wouldn’t need to install Corepack.

[richardlau]

I think we publish binaries both with and without Corepack, right? Do we (or could we) publish binaries both with and without npm?

We only publish a standalone exe (i.e. not bundled with anything) on Windows. I don't know the historical reason why it's only that platform that has an unbundled binary available. All other platforms contain npm and corepack.

[GeoffreyBooth]

We only publish a standalone exe (i.e. not bundled with anything) on Windows.

Not an installer that lets the user choose to add npm or not?

Regardless, is my idea feasible?

[richardlau]

The Windows installer allows users to choose whether to install npm (and/or corepack):

I have no experience with the mac installer (not a mac user).

Providing an unbundled binary on other platforms is technically doable but we have to consider things like:

1. Providing bundled and unbundle packages will roughly double the size of our assets per release (since npm/corepack are tiny in comparison to the node binary).
2. Increased user confusion as to what to get (unless we're going to hide or make the unbundled binary way less prominent).

I'm not aware of any Node.js version managers that allow you to manage package manager versions as well. They are all outside of our control (which has always been my concern on promoting them ahead of our binary distributions on nodejs.org).

[wesleytodd]

We are going to have a session next week to discuss this among other things related to the version management story. openjs-foundation/summit#400

[GeoffreyBooth]

I’m not aware of any Node.js version managers that allow you to manage package manager versions as well. They are all outside of our control (which has always been my concern on promoting them ahead of our binary distributions on nodejs.org).

I think @wesleytodd has been looking into this, and there are at least a few that can do both runtime and package manager; asdf and mise, for starters. Our download page already lists installation steps for package managers such as Brew and Chocolatey. I don’t think a version manager needs to be something we control, and if we list several options then it should be pretty obvious that they’re external projects (and we can always add text to emphasize that point if we want).

I’m not sure the increased binary size really matters; that’s not something we pay for, is it? I’m more concerned by whether this adds burden to the release team. And as for increased user confusion, well, the top post on this issue states the goal as getting users to install Node through a version manager, which inherently is going to be more challenging than just downloading and running an installer; but if the more complicated way is what we recommend, then it should probably be the first option I’d think, and we just need to design the page well to make it as clear as possible to guide users through the process. We would still provide the simpler download too, and maybe some text for when it’s appropriate (like for someone just running Node scripts but not developing Node projects, or running Node stuff in CI say).

[richardlau]

I’m not sure the increased binary size really matters; that’s not something we pay for, is it? I’m more concerned by whether this adds burden to the release team. And as for increased user confusion, well, the top post on this issue states the goal as getting users to install Node through a version manager, which inherently is going to be more challenging than just downloading and running an installer; but if the more complicated way is what we recommend, then it should probably be the first option I’d think, and we just need to design the page well to make it as clear as possible to guide users through the process. We would still provide the simpler download too, and maybe some text for when it’s appropriate (like for someone just running Node scripts but not developing Node projects, or running Node stuff in CI say).

Hosting the binaries comes out of sponsorship. We've had to cull nightly builds because we filled up 300TB of disk usage.

[wesleytodd]

I think @wesleytodd has been looking into this, and there are at least a few that can do both runtime and package manager;

I have in the past for work, and I have been refreshing myself on a few I don't use or keep up with recently. That said, I believe that one of the largest challenges here is aligning with how package managers themselves believe they should manage their versions. I think there will be some really good discussions around this. I have my own thoughts on it, but I think my current goal is much more of a "explore options and try to find something the npm team sees as viable". We only ship npm, and so if we cannot find a path which they can get on board with we will continue to be at a direct impasse.

It is quite possible an outcome of this exploration is that Node.js explicitly decides this is not in the projects best interest to manage. But the most important thing which was missed in the past is a public discussion and investigation of the space. Even the previous version management group did not produce enough of a record for us who were not part of it to understand what was discussed and decided on. I have been attempting to reconstruct some of that history so that we don't repeat those mistakes.

[ovflowd]

I assume this issue can be closed? @GeoffreyBooth is there any other actionable, before we're able to make changes on the Node.js Website side of things?

[mcollina]

I'm not sure this is solved.

[GeoffreyBooth]

I think this would be closed once the new recommendation is published on the website.

[mcollina]

That is not linked here, what is that?

[GeoffreyBooth]

That is not linked here, what is that?

#598

No specific recommendation has been written yet.

[mcollina]

Then why is this to be considered solved?

[ovflowd]

Then why is this to be considered solved?

I thought this issue was a prereq sort of issue, since it does make sense for the actual issue to be created on the node.js website repo, as the changes proposed to package maintenance already got merged...

[GeoffreyBooth]

We’ll need a PR to be open on the website repo; I’m not sure we need an issue there as well. This issue plus the website repo PR should be enough to alert both teams of the problem and proposed solution, and then this issue can be closed by that PR landing.

[ovflowd]

PR open :)

[ovflowd]

This got merged already, and so we can close.