npm install failed - Cannot read property 'emit' of null

[Smirne]

Hello, I'm receiving this error while performing npm install in our continuous integration environment.
The build works fine on my machine (node 0.10.36 npm 2.4.1).

This log was seen while downloading dependencies:

npm info attempt registry request try #2 at 10:59:23 AM
npm http request GET https://registry.npmjs.org/deprecated
npm ERR! Linux 3.0.13-0.27-default
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-d"
npm ERR! node v4.2.1
npm ERR! npm  v3.3.6

npm ERR! Cannot read property 'emit' of null
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>
npm ERR! Linux 3.0.13-0.27-default
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-d"
npm ERR! node v4.2.1
npm ERR! npm  v3.3.6

npm ERR! Cannot read property 'emit' of null
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>
npm http 304 https://registry.npmjs.org/deprecated

And this were the final lines of the log.

npm WARN EPEERINVALID karma-jasmine@0.3.6 requires a peer of jasmine-core@* but none was installed.
npm WARN EPEERINVALID karma-phantomjs-launcher@0.1.4 requires a peer of karma@>=0.9 but none was installed.
npm WARN EPEERINVALID gulp-karma@0.0.5 requires a peer of karma@>=0.10 <=0.13 but none was installed.
npm WARN EPACKAGEJSON OCWEB@0.0.1 No description
npm WARN EPACKAGEJSON OCWEB@0.0.1 No repository field.
npm WARN EPACKAGEJSON OCWEB@0.0.1 No license field.
npm ERR! Linux 3.0.13-0.27-default
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-d"
npm ERR! node v4.2.1
npm ERR! npm  v3.3.6

npm ERR! Callback called more than once.
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /data/jenkins/jobs/OCWeb2-angular/workspace/npm-debug.log
Build step 'Execute shell' marked build as failure


npm debug log available here:
https://gist.github.com/Smirne/78a972422463c5c1c315#file-npm-debug-log

[AritzBi]

Have you fixed it?

[Smirne]

No. Sometimes the build works fine, sometimes I get some error on connection, this "emit" problem and the build fails.

[csantero]

I've been getting this same error on npm install in some of my projects. Usually I wind up having to run npm install twice in these projects to complete getting my dependencies.

Here is a stack trace from npm-debug.log:

271179 verbose stack TypeError: Cannot read property 'emit' of null
271179 verbose stack     at TLSSocket.connectionErrorHandler (/home/chris/.nvm/versions/node/v4.2.1/lib/node_modules/npm/node_modules/request/request.js:80:24)
271179 verbose stack     at TLSSocket.g (events.js:260:16)
271179 verbose stack     at emitOne (events.js:82:20)
271179 verbose stack     at TLSSocket.emit (events.js:169:7)
271179 verbose stack     at emitErrorNT (net.js:1253:8)
271179 verbose stack     at doNTCallback2 (node.js:439:9)
271179 verbose stack     at process._tickCallback (node.js:353:17)
271180 verbose cwd /home/chris/Projects/s360
271181 error Linux 3.10.0-229.14.1.el7.x86_64
271182 error argv "/home/chris/.nvm/versions/node/v4.2.1/bin/node" "/home/chris/.nvm/versions/node/v4.2.1/bin/npm" "install"
271183 error node v4.2.1
271184 error npm  v2.14.11
271185 error Cannot read property 'emit' of null
271186 error If you need help, you may report this error at:
271186 error     <https://github.com/npm/npm/issues>
271187 verbose exit [ 1, true ]

This seems to be the offending line from request.js

[taitems]

Having the same issue on a Team City instance only, just bumping for visibility.

[taitems]

For anyone playing along at home: until this is fixed, the workaround for Team City is to into the Version Control Settings and disable the "clean directory" option, and turn off Swabra if you're running it.

This aligns with most people saying they get the above error the first time, and then it goes away on subsequent attempts. Obviously this can introduce other wider Team City build issues related to not having a clean directory, but this is a short term fix.

[brphelps]

Is there something smarter we can do here? Even just a retry would likely work for this specific error. This issue has been open for a while without any additional comment, and it's something that gives the impression to people that NPM fails transiently from time to time, which can be a little unnerving.

@isaacs @othiym23 , are there any well supported workarounds for this?

[arikon]

Still actual in npm@2.15.4

[chadly]

@arikon you need to update your npm: npm install npm -g

It won't help you though, because it happens for me intermittently (more often than not with bigger projects with many dependencies) on the latest: v3.9.0

It happens to me when running on windows. I haven't seen it yet when I run it on ubuntu.

[arikon]

@chadly We can't update to npm@3 because it is too slow =(

[brphelps]

@chadly I don't think 3.X fixes this issue, I'm seeing it regularly on windows machines with 3.x.

[jmyersmsft]

I am definitely seeing this with npm 3.9.2 on node 6.2.0

I believe this is being caused by request/request#1903

[zarenner]

I agree with @jmyersmsft, and have updated request/request#1903 with a trivial repro.

The bug occurs whenever:

1. HTTP keep-alive is enabled
2. A request with a redirect happens (e.g. from github.com to codeload.github.com)
3. The keep-alive period expires

I'll take a look into fixing this at some point over the next week, but if anyone else is already familiar with the request library and wants to, please chime in.

[BobDickinson]

We see this intermittently on clean installs of a fairly complex project. It seems to be more prevalent on Windows machines, and especially so on single board computer environments (like BeagleBone and Raspberry Pi). Though I have definitely also seen it on my Mac dev machine. It typically runs clean on the second attempt of installing into the same location.

It does seem like the underlying problem is in request, and from looking at the several related issues over there, it's not clear to me that the problem is fixed (or well understood). request/request#2028 seems promising, but there seems to be some debate as to whether it actually works, and it's been sitting there for 6 months without getting merged.

I think some attempt by npm to catch the error, clean up, and retry would be great if it can be done (as opposed to waiting for request to definitely fix it and and release the fix, as that does not seem imminent).

[zarenner]

@BobDickinson
The issue in request is understood (at least I believe I do) and I have a PR out request/request#2240, but the maintainers of request have not responded yet.

+@mikeal, @simov for visibility

[BobDickinson]

@zarenner - did not mean to offend. Maybe I wasn't following all the threads of issues and PRs. I saw your comment on request/request#1903 and I mistakenly though you were indicating that this problem was addressed by request/request#2028 (I see now that you were talking about a potentially related issue). The fact that there seemed to be some debate on request/request#2028 as to whether that fix actually did what was intended is what led to my comment.

request/request#2240 looks promising. Let's hope that gets some traction.

[zarenner]

No offense was taken, on the contrary I'm glad there's additional interest here to push a fix (either to request or npm) through :-)

[zarenner]

request has taken the fix and released 2.73. npm simply needs to take request 2.73 now.