Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not use NPM 5.7

github.com

Post reply on HN
Print view View original

81–90 of 233 posts

Re: Do not use NPM 5.7

#81

Post by JorgeGT »

diggan wrote: post #51
reificator wrote: post #20

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

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.

--------------------------------------------------------------------------

Re: Do not use NPM 5.7

#82

Post by kakwa_ »

jlgaddis wrote: post #25

I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…

What you say is 100% true, but I would go one step further and not have npm installed on any production server.

And it's not specific to npm, I would do the same with gem, pip, cpan, etc. Not to mention curl http://ex.io/install.sh | sudo bash.

Call me old school, but personally, I would avoid installing anything from language specific package managers. I would instead either build an rpm/deb package for every dependencies as a single package or if it's too complex, bundle the dependencies and the application in one package which deploys the bundle under /opt/.

That way I only have one source to check in order to see what is installed on my systems. Also, rpm and dpkg tends to be far better at managing what is installed by each package, and far better at uninstalling everything during cleanups.

Also, mixing a language specific package manager and a distribution package manager can have unforeseen side effects as the two can step on one another (for example, I ran into issues recently with a pip install python-consul overlapping with a yum install salt-minion as both of them download python-requests as a dependency).

Re: Do not use NPM 5.7

#83

Post by Silhouette »

mbrumlow wrote: post #57
jguimont wrote: post #33

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…

> It is not expected that updating npm will kill the complete system it is on... Yeah, but that is why you test your deployments BEFORE deploying them. Hell would be had had any developer at my company ran any such command on a production sever. The notion of even running a command at the terminal on a production server is even scary. Things like should be done on build servers which are in general throwaway. Your bu…

This response annoys me, because it's essentially victim-blaming.

Yes, ideally you have some automation and staging in your server setup. We're grown-ups. We understand this. But it ignores many other dangerous possibilities here.

Not everyone is blessed with working in a mature, well-funded environment full of experts. Maybe we're talking about a new or small organisation that simply doesn't have the resources and/or knowledge to isolate things with containers or VMs and related admin tools.

Maybe even taking out a staging server is still going to waste significant time resetting everything, blocking other development/deployment jobs in the meantime.

Maybe we're not talking about a server at all, but a developer's personal development workstation where they just use NPM to install a few Node-based tools.

It's all very well saying npm shouldn't be run on production servers, but that doesn't really address the fundamental problem. Do we also ban system package managers, and say the only way to deploy anything is via some sort of imaging tool? What if there's an equivalent screw-up in that orchestration tool and it bricks all 100 servers at once?

Re: Do not use NPM 5.7

#84

Post by sametmax »

amelius wrote: post #38
jlgaddis wrote: post #25

I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…

What strikes me as odd is that there are a lot of immature comments in that thread.

There is nothing odd about it. The JS community is today attracting most script kiddies.

During the bubble, it was the same with PHP, and some of us were part of it.

Youngsters must start to code somewhere.

Re: Do not use NPM 5.7

#86

Post by Piskvorrr »

y4mi wrote: post #76
Piskvorrr wrote: post #63

Earlier quoted context omitted.

dpkg will throw a fit in the same way.

it will throw an error message, which the user is probably going to ignore and install anyway. This will ultimately cause errors down the line. Maybe not right now, but eventually problems will occur. showing a warning is great, but not needing that warning would be preferable. but most distributions are already working on solutions to that. ubuntu is working on SnapOn's [0] for example, and i remember hearing about…

Actually, it will throw an error - on which the higher-level (libapt) tools above dpkg will abort, and going directly to dpkg with a --force-whatever is not quite as easy as clicking "yeah, just do it already". Not to mention that I have needed that twice in a decade, in rather obscure cases.

But yeah, containerizing the apps is probably a way forward, which sidesteps whole classes of issues.

Re: Do not use NPM 5.7

#87

Post by plorkyeran »

CJefferson wrote: post #79
carussell wrote: post #55

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…

If I run npm without -g, it complains about missing files, and fills my home directory with node_modules junk and a package-lock.json I have to "commit"? Why do I want to commit it, and where? I'm sure you are now going to tell me there is an easy way to fix that too, and I'd be happy if there was, but for me I just want to use npm to install a program or two.

The correct way is to use `npm install -g --prefix` to install it into a directory on your path which is writeable by your current user.

I don't think I've ever seen the install instructions for a npm-packaged tool actually say to do this.

Re: Do not use NPM 5.7

#89

Post by Silhouette »

hysan wrote: post #19

Doesn't really surprise me when you have other issues like this ( https://github.com/npm/npm/issues/17929 ) that have persisted for a long time. NPM 5.x in general hasn't been very stable.

NPM 5.x in general hasn't been very stable.

Indeed. Another odd thing that it's been doing lately is when I run some NPM scripts on one of our machines, it starts shouting about some sort of update not working (why was it updating anything at all just because I ran `npm run something`?) and gives me instructions on how to fix it from the Linux shell (on a Windows box). The depth of failure implied by that message is disturbing on several levels.

Re: Do not use NPM 5.7

#90

Post by predakanga »

zdragnar wrote: post #32
jergason wrote: post #22

Earlier quoted context omitted.

FWIW the comment you're calling out here is four years old: https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a69... , before npm inc was formed. The correctMkdir change seems more recent, but not really related to that specific comment.

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

Post reply on HN