Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

v3.5.2
Compare
Choose a tag to compare
@iarna iarna released this 04 Dec 02:54
· 1886 commits to latest since this release
v3.5.2
d48783c

v3.5.2 (2015-12-03):

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.

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→[email protected] to a→d→b→[email protected] without moving or removing [email protected] and while leaving [email protected] 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 [email protected] in place so that other moves (or removes) could handle it, but we were stomping on the destination and so [email protected] was being removed.

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.

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:

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.

DEPENDENCY UPDATES

Assets 2
Loading