Live data from Hacker News

Do not use NPM 5.7

github.com

91–100 of 233 posts

Re: Do not use NPM 5.7

#91

Earlier quoted context omitted.

`sudo npm install -g` is one of several examples of the normalization of deviance rife in the NodeJS community. Most command-line utilities distributed through NPM recommend running as root (implicitly—because they all suggest installing it as a global package). Here's[1] Microsoft's instructions to install the TypeScript compiler, for example. NPM's awfulness notwithstanding, it's trivial to write a shell script to…

I'm mostly a Windows user, so maybe I'm misunderstanding *nix stuff here, but I don't see how recommending npm i -g package is remotely the same as recommending sudo npm. Could you clarify?

On Linux you can’t install globally without sudo. Unlike on Windows global means system global, not user-global. Such a thing does simply not exist for Linux’s npm.

If they fixed that, 99% of these issues would go away. This is actually an example of something from the node universe working better on Windows.

Re: Do not use NPM 5.7

#92
post #24

Apart from being a horrific bug, why are people running npm as root? Why don't they install it somewhere below $HOME and modify $PATH? npm is working fine without root permissions. Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.

`sudo npm install -g` is one of several examples of the normalization of deviance rife in the NodeJS community. Most command-line utilities distributed through NPM recommend running as root (implicitly—because they all suggest installing it as a global package). Here's[1] Microsoft's instructions to install the TypeScript compiler, for example. NPM's awfulness notwithstanding, it's trivial to write a shell script to…

~/bin is not in the PATH for many systems. So, if you want beginners to be able to use your program, you'd have to provide instructions on how to change the PATH on each platform that requires it. Then you have to hope that they don't accidentally screw anything up in their profile scripts while making the changes, as I did back when I was new to Linux.

It's extra-frustrating writing those instructions, because not only are they platform-specific, but they are different depending on what the user has already done to their system. If some other tool told them to create ~/.bash_profile or ~/.bash_login, the more shell-agnostic option of modifying ~/.profile will no longer work.

Figuring out where to change the PATH is also confusing, and you might come across solutions that seem to work, but cause weird errors later down the road. For example, the tool being unavailable when invoked remotely, because you only changed the PATH for interactive shells.

It's understandable that people use sudo when they don't see it causing any obvious problems. Installing user-local packages should be one simple command, and it's a failure of operating systems and package managers that it's not. As it stands, correct usage is much harder than incorrect usage, and this is the result.

Re: Do not use NPM 5.7

#93
post #43

Earlier quoted context omitted.

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, an…

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…

> 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.

Re: Do not use NPM 5.7

#94
post #44

Earlier quoted context omitted.

I am the one who reported this ;) In fact that was a single production server that I tried to reinstall 3 times before catching it was not really one of the commits that was doing this. No data was lost or connectivity (as long as you do not reboot it), you just lose any ssh connection/login. Should I have done this on a staging server? Sure, but that does not change the fact that I would have had to rebuild the whol…

The real fix is to not run npm with sudo. Why would you do that in the first place? npm runs install-scripts when you fetch packages, so you basically open up root access for all the packages you download.

[deleted]

Re: Do not use NPM 5.7

#95

Earlier quoted context omitted.

Because sometimes you are writing software that interacts with hardware at a root level. This is really annoying advice you're giving since its absolute and without context. No, not everything is "super dangerous" with sudo. Get that FUD outta here!

Running npm as root is _super dangerous_ - full stop. npm install can run a large amount of arbitrary code downloaded from the internet via postinstall script hooks. Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.

It's banana-pants crazy to run npm at all. Even given all the wisdom about running as sudo, best practices etc., this team released an update where `sudo npm --help` breaks the operating system. The recklessness and confusion of ideas that indicates... postinstall hooks, I don't even want npm running. This isn't even the first such shenanigans.

Re: Do not use NPM 5.7

#96

Earlier quoted context omitted.

This could be my inner grumpy old man speaking, but as a general rule of thumb, I look very poorly on editorializing in code comments. Originally because I didn't want my junior devs embarrassing the company when our clients received control of the code we wrote, but that also transferred into my perception of open source. That comment should not have survived 4 years. Again, inner grumpy old man showing through. Edi…

I can see your point (particularly with regard to deliverables), but I suspect the practice is quite widespread - comments often end up being used as a sort of brain dump. For instance, see this article (from 2004) on comments in the Win2k source code: http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html

That's a fair enough point, especially when directly employed working on closed source / proprietary code. You're essentially stuck in an echo chamber, and professional standards are more difficult to maintain when you don't have the whole of the world looking on.

I also imagine that the mental strain of figuring out edge cases and poor documentation in a system as complex as a windows OS would be enough to make anyone at least a little salty.

However widespread it may be, that does not me that I have to like it :D

Re: Do not use NPM 5.7

#97

Earlier quoted context omitted.

Because sometimes you are writing software that interacts with hardware at a root level. This is really annoying advice you're giving since its absolute and without context. No, not everything is "super dangerous" with sudo. Get that FUD outta here!

Running npm as root is _super dangerous_ - full stop. npm install can run a large amount of arbitrary code downloaded from the internet via postinstall script hooks. Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.

If it runs untrusted code from the Internet, surely it doesn't matter much if you do it as root for most practical purposes? It could still run that spam relay, botnet software, exfiltrate your secrets and install that keylogger.

Re: Do not use NPM 5.7

#98
post #44

Earlier quoted context omitted.

I am the one who reported this ;) In fact that was a single production server that I tried to reinstall 3 times before catching it was not really one of the commits that was doing this. No data was lost or connectivity (as long as you do not reboot it), you just lose any ssh connection/login. Should I have done this on a staging server? Sure, but that does not change the fact that I would have had to rebuild the whol…

The real fix is to not run npm with sudo. Why would you do that in the first place? npm runs install-scripts when you fetch packages, so you basically open up root access for all the packages you download.

How is this different than running apt or yum or pacman or most other package managers as sudo?

Somebody has to install system software.

Re: Do not use NPM 5.7

#99
post #3

Excuse me, but what the fuck? Looks like the line responsible checks if the npm binary is run as sudo and then uses the UID and GID of the invoking user when chowning the directory. [ https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd... ] I feel like screaming, who thought this was a good idea? If I invoke something as sudo, why does anyone think it should try to detect that and do anything about it? I wan…

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, an…

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.

Re: Do not use NPM 5.7

#100
CI/CD does not mean deploying code to production by fetching source code from GitHub onto a server used by your customers and then compiling or downloading NPM dependencies.

That is a recipe for disaster.

Post reply on HN