When using either node 0.10.19 or 0.11.7 it is seemingly impossible to run npm install successfully first time with a large dependency list (49 first level dependencies) . At arbitrary points in the installation process errors like this are seen :
npm ERR! cb() never called!
npm ERR! not ok code 0
The command "npm install" failed. Retrying, 2 of 3.
npm ERR! Error: shasum check failed for /home/travis/tmp/npm-971-ZLjLyYv9/1378478406714-0.9797422615811229/tmp.tgz
npm ERR! Expected: acf472ac07defc6d090976be0e37aebb2e796911
npm ERR! Actual: 7e6740962c5ede06b9dca457b0f1408b6acd64c4
npm ERR! at /home/travis/.nvm/v0.11.7/lib/node_modules/npm/node_modules/sha/index.js:38:8
npm ERR! at ReadStream.<anonymous> (/home/travis/.nvm/v0.11.7/lib/node_modules/npm/node_modules/sha/index.js:85:7)
npm ERR! at ReadStream.EventEmitter.emit (events.js:125:20)
npm ERR! at _stream_readable.js:896:16
npm ERR! at process._tickCallback (node.js:317:11)
npm ERR! If you need help, you may report this log at:
npm ERR! <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR! <firstname.lastname@example.org>
npm ERR! System Linux 2.6.32-042stab061.2
npm ERR! command "/home/travis/.nvm/v0.11.7/bin/node" "/home/travis/.nvm/v0.11.7/bin/npm" "install"
npm ERR! cwd /home/travis/build/Bizzby/bizzby
npm ERR! node -v v0.11.7
npm ERR! npm -v 1.3.8
npm ERR! Additional logging details can be found in:
npm ERR! /home/travis/build/Bizzby/bizzby/npm-debug.log
npm ERR! not ok code 0
The command "npm install" failed. Retrying, 2 of 3.
These tests are all been run on travis which uses a fresh build environment every time.
I'm going to try and reference all the other tickets which seem to be related to the bug to make everyones lives easier (I hope) - Feel free to add any I have missed (there are probably many)
Same thing here. Cant install a single package on the remote machine.
For what it's worth, my Heroku is now completely unable to install from my package.json. Unsure what version they're running. https://cloudup.com/crPk40rzmGI
@andRyanMiller By the looks of it they are using node 0.10.19 with npm 1.2.30 which at first sight seems a non-standard combo considering even node 0.10.18 shipped with npm 1.3.8, but maybe it's taken from your 'package.json'? have you tried a build specifying npm 1.3.8?
@sandfox Package.json was off - bumped to 1.3.8 yet error persists. https://cloudup.com/cdEYyjACCNa. Solution was to drop Node version to 0.10.17 for the time being.
@andRyanMiller did you try 0.10.18? If so did that fail for you too?
@andRyanMiller my solution was the same as yours, drop node down to 0.10.17 in order to get npm to install properly again. I should note, this issue only happens for me when the --production flag is set (like it is in Heroku)
I tried node v0.10.19 with npm 1.3.11, 1.3.8, and 1.2.30 and it fails in a consistent manner after getting ~20 packages.
This problem exists on Linux (via Heroku), on Windows XP (my environment), and OSX 10.8.5 although much more intermittently.
As my other issue was closed, I hope it is OK that I continue here on this one.
I can see that downgrading has worked for some users here; not so for me. I have tried several versions from 1.10.10 and up, and all of them seem to generate the same error message. I am behind a corporate firewall and proxy, but I have never experienced this issue before. My Macintosh is on the same network, but does not have the same issues. Both the macintosh and the windows macine have npm configured with proxy and https-proxy settings, and strict-ssl set to false.
If you need me to run any tests, just shout.
Please try the solution in #2907
This did not fix my issue. Would you like me to continue in this issue or my original one? (#3945)
Didn't mean to close this
@bendiksolheim could attach / post the output of npm install with the new version of node (0.10.20). At a total guess, I'm guessing the fix works well on linux, but maybe not so much for windows...
Ok, so I made new gists with the new logs:
Normal logging: https://gist.github.com/bendiksolheim/6779446
Silly logging: https://gist.github.com/bendiksolheim/6779506
One thing I noticed is that it tries to write to the AppData\Local\Temp. The setup on these machines is a bit special, as the user home-folder is actually mapped to a network drive. I know this has been causing problems when using Maven before. The weird thing is that when installing for example expressjs or grunt, I get no errors, so I don't really think it should matter.
It seems that the latest version of NodeJS causes problems with npm. Going back to version 0.10.17 of NodeJS fixed the issue for me. Just had to fix this at work, no idea if any versions newer than 0.10.17 will work.
@sedushi - 0.10.20 should fix the problem (it was something TLS related in core).
What O/S are you on?
@sandfox I am on Ubuntu 12.04. And I did end up trying it with 0.10.20 and it worked fine as well.
I belive I might have gotten a bit closer to the issue. I found that socket.io also fails on me, with the exact same error message as before. It also failed on zeparser, as is the case with karma. The latest version of zeparser (0.0.7) seems to install just fine, but socket.io and karma both installs version 0.0.5, and when I install that exact version with npm install email@example.com it fails with the same error message as with karma and socket.io.
npm install firstname.lastname@example.org
After som diggin around, the problem on socket.io is the following dependency chain:
Socket.io -> socket.io-client -> email@example.com -> firstname.lastname@example.org
And because socket.io is a dependancy of karma, this also affects karma.
I don't know if this is the correct place to ask, but does this indicate that there is an error in the package itself, or could it be a corrupt package in the npm repository? Or maybe some weird issue on my machine?
Is there a way for me to force use of email@example.com when installing karma and just cross my fingers that it will work, or do I need to wait until the developers update their dependency list?
@bendiksolheim does npm cache clean work for you before retrying it with the stable version of node?
npm cache clean
npm cache clean does not change anything. I have attached logs of installing just firstname.lastname@example.org with the latest stable version:
Silly logging: https://gist.github.com/bendiksolheim/6863268
I noticed something interesting: the "Actual" shasum printed in those logs changes each time i run npm install email@example.com. So I downloaded the file (which I got from npm info firstname.lastname@example.org: tarball: 'http://registry.npmjs.org/zeparser/-/zeparser-0.0.5.tgz') directly with wget and computed the sha1sum with some windows utility, and this checksum is the same as the one I get from npm info email@example.com. So it seems that when I download the file directly everything works OK, but not when I download it with npm. I also checked the file that is downloaded to the Temp folder (tmp.tgz). This file was only 1944 bytes, while the one I downloaded with wget is 2.1 MB. 7zip does not recognize tmp.tgz as a valid archive either.
npm info firstname.lastname@example.org
I finally got hold of another windows laptop to do some more testing, and it might seem like it is the network here that messes things up. When using regular 3G on my phone, everything installed fine. I will contact the network department here and try to do some testing with them, so please just put this on hold so you won't waste any more time on it :)
Ok, this will be the last update from me :)
I have finally found the problem. It turned out to be a firewall issue that was giving us problems. The reason I did not expect it to be the firewall was that downloading the file with curl, wget or a browser worked fine. Even the checksum turned out to be correct then. However, for some reason it blocked the request when npm tried installing the package. I still have no clue as to why exactly it blocks this exact file from being accessed by npm, we simply fixed the issue by tunnelling traffic to registry.npmjs.org through the firewall.
I hope this hasn't caused too much hassle for you, and I am sorry for any inconvenience. In retrospect I should have suspected the firewall much earlier. Thank you for the patience :) I consider the issue solved, so you may close the issue if you would like.
@bendiksolheim Awesome to know you've found the problem. Going to close this now as I'm pretty sure everyones problems are now fixed with the new node releases and firewall fixes