Weeeelcome to another npm release! The short version is that we fixed some ENOENT and some modules that resulted in modules going missing. We also eliminated the use of MD5 in our code base to help folks using Node.js in FIPS mode. And we fixed a bad URL in our license file. FIX URL IN LICENSE The license incorrectly identified the registry URL as registry.npmjs.com and this has been corrected to registry.npmjs.org. cb6d81b #10685 Fix npm public registry URL in notices. (@kemitchell) ENOENT? MORE LIKE ENOMOREBUGS The headliner this week was uncovered by the fixes to bundled dependency handling over the past few releases. What had been a frustratingly intermittent and hard to reproduce bug became something that happened every time in Travis. This fixes another whole bunch of errors where you would, while running an install have it crash with an ENOENT on rename, or the install would finish but some modules would be mysteriously missing and you'd have to install a second time. What's going on was a bit involved, so bear with me: npm@3 generates a list of actions to take against the tree on disk. With the exception of lifecycle scripts, it expects these all to be able to act independently without interfering with each other. This means, for instance, that one should be able to upgrade b in a→b→c without having npm reinstall c. That works fine by the way. But it also means that the move action should be able to move b in a→b→c@1.0.1 to a→d→b→c@1.0.2 without moving or removing c@1.0.1 and while leaving c@1.0.2 in place if it was already installed. That is, the move action moves an individual node, replacing itself with an empty spot if it had children. This is not, as it might first appear, something where you move an entire branch to another location on the tree. When moving b we already took care to leave c@1.0.1 in place so that other moves (or removes) could handle it, but we were stomping on the destination and so c@1.0.2 was being removed. f4385d8 #10655 Preserve destination node_modules when moving. (@iarna) There was also a bug with remove where it was pruning the entire tree at the remove point, prior to running moves and adds. This was fine most of the time, but if we were moving one of the deps out from inside it, kaboom. 19c626d #10655 Get rid of the remove commit phase– we could have it prune just the module being removed, but that isn't gaining us anything. (@iarna) After all that, we shouldn't be upgrading the add of a bundled package to a move. Moves save us from having to extract the package, but with a bundled dependency it's included in another package already so that doesn't gain us anything. 641a93b #10655 Don't convert adds to moves with bundled deps. (@iarna) While I was in there, I also took some time to improve diagnostics to make this sort of thing easier to track down in the future: a04ec04 #10655 Wrap rename so errors have stack traces. (@iarna) 8ea142f #10655 Add silly logging so function is debuggable (@iarna) NO MORE MD5 We updated modules that had been using MD5 for non-security purposes. While this is perfectly safe, if you compile Node in FIPS-compliance mode it will explode if you try to use MD5. We've replaced MD5 with Murmur, which conveys our intent better and is faster to boot. f068b26 #10629 unique-filename@1.1.0 (@iarna) dba1b24 #10629 write-file-atomic@1.1.4 (@othiym23) 8347a30 #10629 fs-write-stream-atomic@1.0.5 (@othiym23) DEPENDENCY UPDATES 9e2a2bb nodejs/node-gyp#831 node-gyp@3.2.1: Improved *BSD support. (@bnoordhuis)