npm install hanging

[chrismademe]

This seems to be happening no matter what package I want to install, I've tried removing npm and node completely and re-installing to no avail.

I've also tried installing Grunt and it hangs at various points it's never consistant.
The latest is Gulp...

$ sudo npm -d install gulp -g
npm info it worked if it ends with ok
npm info using npm@2.11.3
npm info using node@v0.12.7
npm info attempt registry request try #1 at 2:38:12 PM
npm http request GET https://registry.npmjs.org/gulp
npm http 304 https://registry.npmjs.org/gulp
npm info install gulp@3.9.0 into /usr/local/lib
npm info installOne gulp@3.9.0
^CResknows-iMac:~ resknow$ gulp -v
-bash: gulp: command not found
Resknows-iMac:~ resknow$ sudo npm -d install gulp -g
npm info it worked if it ends with ok
npm info using npm@2.11.3
npm info using node@v0.12.7
npm info attempt registry request try #1 at 2:38:50 PM
npm http request GET https://registry.npmjs.org/gulp

It just sits there with the spinning /...

Any help would be greatly appreciated, it's driving me crazy :(

[shri3k]

Hey @chrismademe, I know you've tried lot of things but try giving npm cache clean a shot and then when installing use the flag --loglevel=silly.
Like :-
npm i gulp -g --loglevel=silly
and see if you get any feedback.

[chrismademe]

Hi @sinkingshriek, thanks for your advice. I've done the above on both Gulp and Grunt and the results are much the same. In fact I'm on a fresh machine that had never had Node/NPM at all until 5 minutes ago.

I won't paste the whole lot becuse it's very long, but Grunt gets stuck here:

npm verb addTmpTarball already have metadata; skipping unpack for iconv-lite@0.2.11
npm sill cache afterAdd iconv-lite@0.2.11
npm verb afterAdd /Users/idachris/.npm/iconv-lite/0.2.11/package/package.json not in flight; writing
npm verb afterAdd /Users/idachris/.npm/iconv-lite/0.2.11/package/package.json written

and just twiddles the /

and Gulp gets stuck here:

npm verb rebuildBundles orchestrator@0.3.7
npm verb rebuildBundles [ 'end-of-stream', 'sequencify', 'stream-consume' ]
npm info install orchestrator@0.3.7
npm info postinstall orchestrator@0.3.7
npm verb unlock done using /Users/idachris/.npm/_locks/orchestrator-272f6829485ce7a7.lock for /usr/local/lib/node_modules/gulp/node_modules/orchestrator

I'm all out of ideas :(

[shri3k]

Hm..That's strange. Depending on the size and the network it does feel like it's stuck at times. But let's give it a final shot. Try :-
npm list -g | less -n 1 and check the first line. That's where all your global packages gets installed.
Go to that directory and delete node_modules directory.
Run npm cache clean again and try installing one more time.
Let's first install simple packages with least dependencies like string2array (npm i -g string2array) and wait for some time. If it still shows no progress then I've had very good luck with nvm.

[addyosmani]

I've been running into this issue over the last 8 hrs with node 0.12.7 and npm 2.13.3 as well as 2.11.3.

Any attempt to npm install dependencies from checked out git projects like material-design-lite are resulting in a varied % of deps installing, followed by it getting stuck and hanging there without progress.

I've attempted to downgrade node, downgrade npm, re-clean my caches, inspect the installation trace using -dd, even switch back and forth between the EU npm registry mirror but there doesn't seem to be any consistency to where things are getting stuck. I've also restested my network setup and I'm having no issues rapidly fetching binaries from elsewhere so it's not that.

Here's a partial log from loglevel=silly. The weirdest thing is that prior to today, all my installations were working fine. I hadn't touched bumping npm for at least a few weeks. Part of me wonders if this is a registry issue, but it's likely not.

[shri3k]

@addyosmani So, I did try material-design-lite project and yes, it does take quite a while to install all packages and if you're not in npm v3+ then it's possible that you don't even see the progress (apart from just the spinner) but I do see progress bar moving and some activity happening on installing packages.
I do have to note that I'm on node 0.12.2 (I tend to avoid odd versions cause they're supposed to unstable version) and in npm v3.2.0. However, I did get Maximum calls tack size exceeded error during the process and this might be a totally different issue.

[othiym23]

@addyosmani I'm seeing some evidence that there was something up with the registry today, at least when accessed from some locations. It could be that something was up with our CDN, and it's also possible that something was up with GitHub (do the projects you were installing have any / many dependencies on GitHub?). Can you do me a favor and give your installs another shot tomorrow and tell me if this is still a problem? (Either way, I apologize for the inconvenience – we work hard to make sure the registry is reliable, and it's been so long since we've had these kinds of issues that I'm a little baffled as to what could be happening.)

[chrismademe]

Morning guys,

Thanks for all the responses. I've tried again this morning with the same results unfortunately :(

npm verb afterAdd /Users/resknow/.npm/semver/4.3.6/package/package.json written
npm verb afterAdd /Users/resknow/.npm/v8flags/2.0.10/package/package.json written

Gulp gets stuck there, at varying points but it always seems to be after the "package.json" written now.

[addyosmani]

Thanks @othiym23 and no need to apologise. I can imagine it's non-trivial maintaining complete stability of both the registry and client at all times :)

I re-tested yesterday morning and unfortunately ran into the same situation as @chrismademe above.

[chrismademe]

I'm in no rush to get this going so I'll leave it for now. I appreciate all the hard work that goes in to running and maintaining a system of this size.

Thanks for everyone's help :)

[petecarapetyan]

I am seeing this same problem today after weeks and weeks of other npm challenges with more workarounds than I can possibly even document. Never have I appreciated java and maven so much. The nodejs community has 100x more patience for dependency hell than I could ever come up with.

[maurowalter]

Try clean dependencies folder with problems under ~/.npm, (resknow) and run npm install again.

[sompylasar]

May I ask a question about the npm code that looks related: why is the possible error of writeFileAtomic in the code below looks ignored?

npm/lib/cache.js

Line 362 in d081cc6

if (!er) log.verbose('afterAdd', pj, 'written')

function afterAdd (cb) {
  return function (er, data) {
    adding--

    if (er || !data || !data.name || !data.version) return cb(er, data)
    log.silly('cache', 'afterAdd', data.name + '@' + data.version)

    // Save the resolved, shasum, etc. into the data so that the next
    // time we load from this cached data, we have all the same info.
    // Ignore if it fails.
    var pj = path.join(cachedPackageRoot(data), 'package', 'package.json')

    var done = inflight(pj, cb)
    if (!done) return log.verbose('afterAdd', pj, 'already in flight; not writing')
    log.verbose('afterAdd', pj, 'not in flight; writing')

    getStat(function (er, cs) {
      if (er) return done(er)
      writeFileAtomic(pj, JSON.stringify(data), { chown: cs }, function (er) {
        if (!er) log.verbose('afterAdd', pj, 'written')
        // <<<<<<<< HERE >>>>>>>>>
        // <<<<<<<< HERE >>>>>>>>>
        // <<<<<<<< HERE >>>>>>>>>
        return done(null, data)
      })
    })
  }
}

[npm-robot]

We're closing this support issue as it has gone three days without activity. The npm CLI team itself does not provide support via this issue tracker, but we are happy when users help each other here. In our experience once a support issue goes dormant it's unlikely to get further activity. If you're still having problems, you may be better served by joining package.community and asking your question there.

For more information about our new issue aging policies and why we've instituted them please see our blog post.