My headaches described below were due to my npm module’s dependency clauses’ versioning stanzas. I had set dependencies to automatically update but clipped them to the current minor version. Eventually they got crusty, and npm actually stopped finding the versions I was demanding in a speedy fashion. Both edges of the upgrade knife can cut you, don’t let dependencies get too old. 🙂 Fuller explanation on SO.
Historical blathering follows…
Haven’t figured out why yet, but note to self: node shits itself with dependency problems if you go from 7.2.0 to 8.1.2. Â I’m using nvm to switch around, so switching back was trivial. Â I have my default set to 7.2.0 for now until I have time to figure out what’s going on in more detail.
UPDATE: seems to work again after cleaning out all my local module folders [rm -rf node_modules] and redoing [npm install -g].
UPDATE: I upgraded my box and that kicked off nvm into upgrading npm.  Once you switch npm versions, it starts using an entirely new global cache.  So there you have it.  🙂
UPDATE: Also, on my laptop [viper], I had a stray package-lock.json, a nasty file that locks you out of upgrades, which can screw you over at times. Â Or screw you over if you don’t use one. Â YMMV.
UPDATE: it’s too early to start using this release – roll back to the last LTS, 6.11.2 as of 2017-08-15. Â nvm takes the blame, it gets wonky if you had it pointing to a version that disappears. Â Do this:
m@viper:~$ nvm alias stable lts/boronstable -> lts/boron (-> v6.11.2)m@viper:~$ nvm aliasdefault -> node (-> v6.11.2)node -> stable (-> v6.11.2)stable -> lts/boron (-> v6.11.2)iojs -> N/A (default)lts/* -> lts/boron (-> v6.11.2)lts/argon -> v4.8.4 (-> N/A)lts/boron -> v6.11.2
UPDATE: nvm with lts is the new solution
nvm install --lts
Also, IRONICALLY, be careful trying to control dependency versions, as they may actually go out of favor and slow npm down trying to extract them. On occassion, in controlled fashion, upgrade your dependencies. This is the only truth in today’s development world.
