Live data from Hacker News

Do not use NPM 5.7

github.com

151–160 of 233 posts

Re: Do not use NPM 5.7

#151
post #82

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 depend…

The ironic part here is, part of npm's core design - installing all deps to `./node_modules` - makes it extremely easy to "build" on one machine and then zip up the whole project directory which only needs `node` to run.

This is in fact way easier than options for python, ruby (and probably many others) which tend to install versioned dependencies to some shared directory and then add them to the path at runtime. So you're very right, it's trivial to not need npm at all, ever, in production.

Re: Do not use NPM 5.7

#152
post #76

Earlier quoted context omitted.

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…

No, it will not install the package at all: $ mkdir root/bin/ $ (echo '#!/bin/sh'; echo 'echo "hi"') > root/bin/ls $ chmod +x root/bin/ls $ fpm -s dir -t deb -n bad-ls -v 1.0 -C `pwd`/root . Created package {:path=>"bad-ls_1.0_amd64.deb"} $ dpkg-deb -c bad-ls_1.0_amd64.deb drwxrwxr-x 0/0 0 2018-02-22 10:44 ./ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/ drwxr-xr-x 0/0 0 2018…

this is strange. I encountered a conflict at work recently with an /etc/ file conflict.

the stdout of the dpkg errormsg gave me the required tag i could use to do it anyway. it was basically just

  !! double click -> middle click

Re: Do not use NPM 5.7

#153
From: https://github.com/npm/npm/releases/tag/v5.7.1

"Thankfully, it only affected users running npm@next, which is part of our staggered release system, which we use to prevent issues like this from going out into the wider world before we can catch them. Users on latest would have never seen this!"

If you are updating to the latest pre-release of something within mere hours of it dropping and you are updating production systems (presumably that have some business value) with no previous testing then the consequences of that aren't on the devs they are 100% on you. And you don't deserve to call yourself an IT (or Ops or DevOps or what-have-you) professional, that is amateurish behavior in the extreme.

Re: Do not use NPM 5.7

#154
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…

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.

Re: Do not use NPM 5.7

#155
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…

The entire JS ecosystem is a case study in trying to be too clever on a well-solved problem.

Re: Do not use NPM 5.7

#156
It's been almost 2 years since the great left-pad debacle[0]. The last major npm issue[1] was less than 2 months ago. While the underlying npm registry security issues will remain for a while (and other languages don't seem to have these issues with their package managers), there doesn't seem like there's too much I can do other than use yarn. And hope an alternative registry will appear.

Since I 'vote' with my code - this migration page has been helpful today - and I hope it will help others: https://yarnpkg.com/lang/en/docs/migrating-from-npm/

It took me ~5 mins to migrate all of my code from npm to yarn. But I don't have complex CI tasks either.

I use ncu to check updates every couple of days, sometimes more frequently. To further distance myself from npm, can anyone comment on the pros/cons of github repo paths instead of package names in package.json?

[0] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos

[1] https://github.com/npm/registry/issues/255

*edit: formatting

Re: Do not use NPM 5.7

#157

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.

Yeah, it would really suck if those files installed by my operating system--the ones that are trivially verified and easily replaced as they are literally the same on every single computer--were to be damaged. Things are much safer if I run them as the user which owns all of my data and which I spend all my time logged in as, right? I mean, at least I haven't stupidly added any part of my home directory to my path, so I can trust that the software I am running was installed by someone running as root... oh wait :/.

The only reason root even exists on a computer that has two users (root and the user that owns all the data) is to make sure that no software is installed on the system except by root. If you have things set up to also let you install software as the user that isn't root, then you have somehow missed the entire point of peiviledge separation and should just log in as root and do everything as root, as that is at that point fully equivalent.

Re: Do not use NPM 5.7

#159

It's been almost 2 years since the great left-pad debacle[0]. The last major npm issue[1] was less than 2 months ago. While the underlying npm registry security issues will remain for a while (and other languages don't seem to have these issues with their package managers), there doesn't seem like there's too much I can do other than use yarn. And hope an alternative registry will appear. Since I 'vote' with my code…

Github paths can change way more easily than npm packages, users can rewrite git history + break your stuff and versioning when using it with npm is horrible. NPM also now protects projects from namesquatting and prevents you from deleting them when multiple projects depend on them.

Re: Do not use NPM 5.7

#160

It's been almost 2 years since the great left-pad debacle[0]. The last major npm issue[1] was less than 2 months ago. While the underlying npm registry security issues will remain for a while (and other languages don't seem to have these issues with their package managers), there doesn't seem like there's too much I can do other than use yarn. And hope an alternative registry will appear. Since I 'vote' with my code…

The left-pad debacle was a registry issue but the current issue is an npm client issue. In my experience, NPM 5 client versions have been shaky and unreliable, and there are problems with popular ecosystems like react-native [0]. I always roll back to npm 4, even on node 9.

[0] https://github.com/facebook/react-native/issues/14209

Post reply on HN