Hacker News Reader

Comment by tbrock | Hacker News Reader

> npm is fantastic

We must live on different planets. Our eng team and CI tool needs to run npm install multiple times to coerce this lumbering beast into writing all of our requirements into a directory.

Every time it unreliably installs my dependencies as specified (after declaring exact versions required in my package.json) I scream into the void "you had one job!". It's a frequent cause of frustration for me despite providing access to a wonderfully colorful library of software.

Availability of packages on npm and in the larger JS ecosystem is at an all time high and yes, JS as a language seems to be doing well, but npm is, in my opinion, in dire need of some tlc.

View on HN

> Every time it unreliably installs my dependencies as specified (after declaring exact versions required in my package.json)

Declaring exact versions in your package.json doesn't make installs consistent. An example:

     A's package.json says A needs exactly B version 1.2.0
       B's package.json says B needs C version 2 or newer
         C can be any version.

shrinkwrap will help you with this. It's better in npm v3 (install updates shrinkwrap by default)

I'd agree with you but it misses packages at the top level entirely until I run install twice. I am saying install blah@x and it doesn't realize I need it until round 2.

Ok thanks for down voting me but see others having the same problem here https://github.com/npm/npm/issues/10727

FYI it's not me that's downvoting. Your original comment was just 'I know but it still happens' so you may have been downvoted by someone who thought it lacked detail.

I made a batch file to run npm 3 times when they had a bug in assuming atomic file actions. They have fixed this bug and the latest versions of npm. It only happened on cloud servers for me and it was assumed a result of slow IO highlighting the bug.

Eh I'm not sure that is the same problem. We could reproduce this behavior on everything from MacBook Airs to honking i7s with fast SSDs as well as the cloud.

The case you describe definitely sounds "broken" to me. I think it'd be very, very helpful if you could provide your test cases to the npm project.

It's already well documented here https://github.com/npm/npm/issues/10727

I have to wonder if you're doing it wrong. We have a very large angular/node app, which has been in production for 2.5 years, with many packages. We npm-install several times per day on different networks and different machines. The only time we have had problems is when the actual npm site itself goes down (thankfully that's rare now but it was annoyingly frequent "in the beginning"). Npm-shrinkwrap is a little painful but gets the job done. I don't hear a lot of people having problems with npm. It kind of "just works" for almost everyone.

Don't get me wrong, we are lucky to have npm at all and I don't want to turn this thread into a vendetta for "my issue" because I hate when people do that but I've obviously struck a chord with the community. I don't think it's just me.

Maybe npm is broken and everyone is either just apologizing for it or complaining instead of fixing it (myself included).

I agree. Fantastic is not what I'd use to describe npm. Mostly it usually works a majority of the time... It's tough to get reproducible deploys even when we have our versions pinned.

Recently I ran into issues with npm global, Jenkins, and Windows Server and I was ready to burn the building down. I give npm a share of the blame, but not all, but the major issue was where npm global installs tried to install when run in Jenkins as a service.

Reply on news.ycombinator.com