5 ms·

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

by tbrock 11y ago

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

sosuke 11y ago
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.
- tbrock 11y ago
  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.
  - jt2190 11y ago
    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.
    - tbrock 11y ago
      It's already well documented here https://github.com/npm/npm/issues/10727 https://github.com/npm/npm/issues/10727
nailer 11y ago
> 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)
- deleted 11y ago
  [deleted]
- tbrock 11y ago
  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.
  - tbrock 11y ago
    Ok thanks for down voting me but see others having the same problem here https://github.com/npm/npm/issues/10727 https://github.com/npm/npm/issues/10727
    - nailer 11y ago
      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.
- deleted 11y ago
  [deleted]
lavamantis 11y ago
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.
- deleted 11y ago
  [deleted]
- tbrock 11y ago
  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).
manyxcxi 11y ago
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.

by tbrock 11y ago

sosuke 11y ago

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.

tbrock 11y ago
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.
- jt2190 11y ago
  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.
  - tbrock 11y ago
    It's already well documented here https://github.com/npm/npm/issues/10727 https://github.com/npm/npm/issues/10727

nailer 11y ago

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

deleted 11y ago
[deleted]
tbrock 11y ago
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.
- tbrock 11y ago
  Ok thanks for down voting me but see others having the same problem here https://github.com/npm/npm/issues/10727 https://github.com/npm/npm/issues/10727
  - nailer 11y ago
    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.
deleted 11y ago
[deleted]

lavamantis 11y ago

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.

deleted 11y ago
[deleted]
tbrock 11y ago
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).

manyxcxi 11y ago

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.