Repository navigation
globally installing npm should not be the recommended way for Mac and Linux #591
Description
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:
- distro-specific packages (deb, rpm, brew, port, ...)
- 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.
Activity
davidfekke commentedon Feb 28, 2024
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 commentedon Mar 5, 2024
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 commentedon Mar 5, 2024
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 commentedon Mar 5, 2024
FYI this issue is about making the package managers (ie NVM) the default tab... (I might have misunderstood your comment)
tniessen commentedon Mar 5, 2024
Sorry, I am a bit confused. Is this about the website redesign or about the current production website?
ovflowd commentedon Mar 5, 2024
Redesign!
ovflowd commentedon Mar 5, 2024
(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 commentedon Mar 5, 2024
I haven't used it in a while but it should not do as on Windows
npm install -ggoes intoAppData\Roaming(e.g.\Users\{username}\AppData\Roaming\npm).mcollina commentedon Mar 5, 2024
Windows installer is ok.
mhdawson commentedon Mar 20, 2024
Transferred to the package maintenance repo as agreed in the TSC meeting today.
wesleytodd commentedon Mar 22, 2024
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 commentedon Mar 25, 2024
Just thought I’d relay part of nodejs/node#51981 (comment) here:
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 commentedon Mar 25, 2024
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.
2 remaining items
wesleytodd commentedon Mar 26, 2024
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 commentedon Mar 26, 2024
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 commentedon Mar 26, 2024
Hosting the binaries comes out of sponsorship. We've had to cull nightly builds because we filled up 300TB of disk usage.
wesleytodd commentedon Mar 26, 2024
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 commentedon May 11, 2024
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 commentedon May 12, 2024
I'm not sure this is solved.
GeoffreyBooth commentedon May 12, 2024
I think this would be closed once the new recommendation is published on the website.
mcollina commentedon May 12, 2024
That is not linked here, what is that?
GeoffreyBooth commentedon May 12, 2024
#598
No specific recommendation has been written yet.
mcollina commentedon May 12, 2024
Then why is this to be considered solved?
ovflowd commentedon May 12, 2024
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 commentedon May 13, 2024
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 commentedon May 13, 2024
PR open :)
ovflowd commentedon Jul 31, 2024
This got merged already, and so we can close.