Global install of lerna fails with 6.9.0

What I Wanted to Do

Install lerna globally via sudo npm i -g lerna.

What Happened Instead

I received the following error:

Unhandled rejection Error: EISDIR: illegal operation on a directory, open '/Users/svencowart/.npm/_cacache/content-v2/sha512/29/f6'

npm ERR! cb() never called!

Reproduction Steps

Run sudo npm i -g lerna with npm@6.9.0.

Details

2019-04-04T16_53_38_897Z-debug.log (439 Bytes)

Platform Info

$ npm --versions
{ npm: '6.9.0',
  ares: '1.10.1-DEV',
  cldr: '32.0',
  http_parser: '2.8.0',
  icu: '60.1',
  modules: '57',
  napi: '3',
  nghttp2: '1.32.0',
  node: '8.11.3',
  openssl: '1.0.2o',
  tz: '2017c',
  unicode: '10.0',
  uv: '1.19.1',
  v8: '6.2.414.54',
  zlib: '1.2.11' }
$ node -p process.platform
darwin

There is an open issue with installing global packages using sudo leaving behind files with the wrong ownership.

The short version is run this to fix the ownership, then try your install again:


sudo chown -R $(whoami) ~/.npm

The long version and canonical bug is: Global installs (sudo npm i -g) fail on Mac after 6.5 upgrade. Works fine after 6.4.1 downgrade.

I tried this but get the same error.

A couple of notes. Wrong permissions (as in root.root owned files in ~/.npm/** left behind when running npm under sudo due to, for instance, pacote #174) cannot directly explain your error, and consequently it is unsurprising that @shadowspawn 's advice to chown your files did not address your problem. The error is that the program tried to read from file /Users/svencowart/.npm/_cacache/content-v2/sha512/29/f6 as if it were a regular file, but this filename does in fact correspond to a directory maintained by the cacache package. (History buffs can read this SO answer for why this doesn’t work.)

The error message ‘cb() never called’ means that the uncaughtException handler npm installed is never invoked. This happens because the failure occurs during an unhandledRejection event for which npm does not install a handler. If you’re interested in tracking this problem down, and you can reliably reproduce it, I would install such a handler. Perhaps the provided error object has information such as a backtrace that would lead you to the point in the code where npm attempts to open this path. My guess, btw, is that npm really means to open one of the files located in that directory, but the logic to compute the filename is faulty and cuts off/omits the last component.

Correction: in lieu of installing a custom handler, set instead bluebird’s longStackTrace options as I describe here.

I was able to resolve my problem by uninstalling node completely and reinstalling from scratch. The issue seemed to be using npm v6.x.x with node v8.x.x. Everything works as intended when using npm v6 with node v8 and npm v5 with node v8.