4 ms·

I completely agree with you. But in fairness, I can't count the number of times that I've needed to fix things after people treated `sudo npm` as Simon Says[1]

I completely agree with you. But in fairness, I can't count the number of times that I've needed to fix things after people treated `sudo npm` as Simon Says[1]. I'm sure they struggled a lot with that issue before coming to this solution. Was it the right solution? Absolutely not. But that's not the point I'm trying to make. It's all too easy to tunnel vision on a particular solution. I've done it plenty of times, and I'm thankful to those who have helped me to see other alternatives in time. [1]: https://xkcd.com/149/ https://xkcd.com/149/

zaarn 9y ago
I think the easy solution here would be to disable global installs. Pip does that same stuff and it also is known to get people's computers into quite advanced states. Ideally npm should simply setup a dedicated directory in /opt or /usr/local/ (ie, /usr/local/node/bin or /opt/node/bin) in which it dumps all the global stuff. That way you can easily set permissions for a user and/or contain any damages to that folder. If npm blows up that way it doesn't murder the entire system, you'll still be able to SSH in. (That is unless you use a SSH agent based on node.js in which case; "why?") Once npm has implemented such a location it should refuse to run with sudo and demand the user setup the correct permissions within the node folder (maybe setup a group "npm-manage" during install?)
- diggan 9y ago
  > easy solution here would be to disable global installs I think that's not optimal. Having package being installed "globally" (as in available on your PATH) is nice. You can install `yarn` by doing `npm install --global yarn`. The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. Instead, default installation should be in user-accessible place and running npm with sudo should be exiting without doing anything.
  - ryanbrunner 9y ago
    I think you're saying the same thing. Later in his comment, he mentions installing "global" stuff to `/usr/local/node/bin` or something like that, which is easy to add to your PATH (and can be scripted / documented to be easy to set up). Essentially do what homebrew does, which never seems to run into problems and IIRC completely refuses to run as root nowadays.
    - to3m 9y ago
      It seems not to be entirely without problems, or at least hassle: https://stackoverflow.com/questions/41840479/how-to-use-homebrew-on-a-multi-user-macos-sierra-setup https://stackoverflow.com/questions/41840479/how-to-use-home...
  - kakarot 9y ago
    > The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. No, like you say in your next sentence the trouble is that it's default. This is NPM's fault, not the user.
  - piva00 9y ago
    I don't get what is the issue on requiring a "global" installation to be added to $PATH, a lot of other tools ask for that during installation and it's by far the safest way to do it.
  - zaarn 9y ago
    I basically want what you mentioned later but also available to other users. Home folder installation only works when you A) only want to install for a user B) the user you run under exists on disk and has a home folder and C) the user can be setup to perform updates. A lot of the time I run tools that will run as a service. The user it runs under might not have a home folder, probably not even a login or shell. I still need access to the tool installed as root and as normal user for maintenance. So ideally, I add the path into /etc/profile and install the stuff into /usr/local/node/bin where it is perfectly isolated from the rest of the system.
diggan 9y ago
I don't remember exactly what tool does this, but one package manager (can be homebrew but long time ago I used homebrew) warns users if you are running it as root, since it should install packages as the user. I think npm could implement a similar strategy and educate the users how packages should really be installed.
- dharmab 9y ago
  Several Arch Linux AUR helpers (pacaur and trizen, for example) refuse to run as root. Instead, they invoke sudo to escalate only during the necessary phases.
  - RX14 9y ago
    That's because makepkg rightly refuses to run as root. ==> ERROR: Running makepkg as root is not allowed as it can cause permanent, catastrophic damage to your system.
- Shank 9y ago
  Homebrew it is! $ sudo brew Error: Running Homebrew as root is extremely dangerous and no longer supported. As Homebrew does not drop privileges on installation you would be giving all build scripts full access to your system.
  - nailer 9y ago
    I really like that message. It used to be something diffr\erent, which was vague, but this actually tells you why it refuses to run as root.
- al2o3cr 9y ago
  Bundler does something similar - it complains if you run the command with sudo. Ignoring the warning can result in exciting permissions errors later, which is what I'm guessing the NPM code is trying to avoid.
- JorgeGT 9y ago
  mpirun will also throw an error if run as root: -------------------------------------------------------------------------- mpirun has detected an attempt to run as root. Running at root is strongly discouraged as any mistake (e.g., in defining TMPDIR) or bug can result in catastrophic damage to the OS file system, leaving your system in an unusable state. You can override this protection by adding the --allow-run-as-root option to your cmd line. However, we reiterate our strong advice against doing so - please do so at your own risk. --------------------------------------------------------------------------
xorcist 9y ago
One would be forgiven to think that npm run as root would install packages to a system wide location, where multiple applications may utilize them without having write privileges to its code. That what pretty much every other package manager does. Not hose your system and irreversibly render it inaccessible.
SilasX 9y ago
I confess, I've resorted to `sudo npm` in a desperate attempt to get something to work at all, when trying to install frontend assets and not being able to make sense of the errors or get a helpful answer out of the frontend team.

zaarn 9y ago

I think the easy solution here would be to disable global installs. Pip does that same stuff and it also is known to get people's computers into quite advanced states. Ideally npm should simply setup a dedicated directory in /opt or /usr/local/ (ie, /usr/local/node/bin or /opt/node/bin) in which it dumps all the global stuff. That way you can easily set permissions for a user and/or contain any damages to that folder. If npm blows up that way it doesn't murder the entire system, you'll still be able to SSH in. (That is unless you use a SSH agent based on node.js in which case; "why?") Once npm has implemented such a location it should refuse to run with sudo and demand the user setup the correct permissions within the node folder (maybe setup a group "npm-manage" during install?)

diggan 9y ago
> easy solution here would be to disable global installs I think that's not optimal. Having package being installed "globally" (as in available on your PATH) is nice. You can install `yarn` by doing `npm install --global yarn`. The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. Instead, default installation should be in user-accessible place and running npm with sudo should be exiting without doing anything.
- ryanbrunner 9y ago
  I think you're saying the same thing. Later in his comment, he mentions installing "global" stuff to `/usr/local/node/bin` or something like that, which is easy to add to your PATH (and can be scripted / documented to be easy to set up). Essentially do what homebrew does, which never seems to run into problems and IIRC completely refuses to run as root nowadays.
  - to3m 9y ago
    It seems not to be entirely without problems, or at least hassle: https://stackoverflow.com/questions/41840479/how-to-use-homebrew-on-a-multi-user-macos-sierra-setup https://stackoverflow.com/questions/41840479/how-to-use-home...
- kakarot 9y ago
  > The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. No, like you say in your next sentence the trouble is that it's default. This is NPM's fault, not the user.
- piva00 9y ago
  I don't get what is the issue on requiring a "global" installation to be added to $PATH, a lot of other tools ask for that during installation and it's by far the safest way to do it.
- zaarn 9y ago
  I basically want what you mentioned later but also available to other users. Home folder installation only works when you A) only want to install for a user B) the user you run under exists on disk and has a home folder and C) the user can be setup to perform updates. A lot of the time I run tools that will run as a service. The user it runs under might not have a home folder, probably not even a login or shell. I still need access to the tool installed as root and as normal user for maintenance. So ideally, I add the path into /etc/profile and install the stuff into /usr/local/node/bin where it is perfectly isolated from the rest of the system.

diggan 9y ago

I don't remember exactly what tool does this, but one package manager (can be homebrew but long time ago I used homebrew) warns users if you are running it as root, since it should install packages as the user. I think npm could implement a similar strategy and educate the users how packages should really be installed.

dharmab 9y ago
Several Arch Linux AUR helpers (pacaur and trizen, for example) refuse to run as root. Instead, they invoke sudo to escalate only during the necessary phases.
- RX14 9y ago
  That's because makepkg rightly refuses to run as root. ==> ERROR: Running makepkg as root is not allowed as it can cause permanent, catastrophic damage to your system.
Shank 9y ago
Homebrew it is! $ sudo brew Error: Running Homebrew as root is extremely dangerous and no longer supported. As Homebrew does not drop privileges on installation you would be giving all build scripts full access to your system.
- nailer 9y ago
  I really like that message. It used to be something diffr\erent, which was vague, but this actually tells you why it refuses to run as root.
al2o3cr 9y ago
Bundler does something similar - it complains if you run the command with sudo. Ignoring the warning can result in exciting permissions errors later, which is what I'm guessing the NPM code is trying to avoid.
JorgeGT 9y ago
mpirun will also throw an error if run as root: -------------------------------------------------------------------------- mpirun has detected an attempt to run as root. Running at root is strongly discouraged as any mistake (e.g., in defining TMPDIR) or bug can result in catastrophic damage to the OS file system, leaving your system in an unusable state. You can override this protection by adding the --allow-run-as-root option to your cmd line. However, we reiterate our strong advice against doing so - please do so at your own risk. --------------------------------------------------------------------------

xorcist 9y ago

One would be forgiven to think that npm run as root would install packages to a system wide location, where multiple applications may utilize them without having write privileges to its code. That what pretty much every other package manager does. Not hose your system and irreversibly render it inaccessible.

SilasX 9y ago

I confess, I've resorted to `sudo npm` in a desperate attempt to get something to work at all, when trying to install frontend assets and not being able to make sense of the errors or get a helpful answer out of the frontend team.