This repository has been archived by the owner. It is now read-only.

@zkat zkat released this Sep 9, 2016 · 1288 commits to latest since this release

Assets 2

Monthly releases are so big! Just look at all this stuff!

Our quarter of monthly releases is almost over. The next one, in October, might very well be our last one as we move to trying something different and learning lessons from our little experiment.

You may also want to keep an eye our for npm@4 next month, since we're planning on finally releasing it then and including a (small) number of breaking changes we've been meaning to do for a long time. Don't worry, though: npm@3 will still be around for a bit and will keep getting better and better, and is most likely going to be the version that node@6 uses once it goes to LTS.

As some of us have mentioned before, npm is likely to start doing more regular semver-major bumps, while keeping those bumps significantly smaller than the huge effort that was npm@3 -- we're not very likely to do a world-shaking thing like that for a while, if ever.

All that said, let's move on to the patches included in v3.10.8!


The most notable part of this release is a series of commits meant to make npm shrinkwrap more consistent. By itself, shrinkwrap seems like a fairly straightforward thing to implement, but things get complicated when it starts interacting with devDependencies, optionalDependencies, and bundledDependencies. These commits address some corner cases related to these.

  • a7eca32 #10073 Record if a dependency is only used as a devDependency and exclude it from the shrinkwrap file. (@bengl)
  • 1eabcd1 #10073 Record if a dependency is optional to shrinkwrap. (@bengl)
  • 03efc89 #13692 We were doing a weird thing where we used a package.json field installable to check to see if we'd checked for platform compatibility, and if not did so. But this was the only place that was ever done so there was no reason to implement it in such an obfuscated manner. Instead it now just directly checks and then records that its done so on the node object with knownInstallable. This is useful to know because modules expanded via shrinkwrap don't go through this– inflateShrinkwrap does not currently have any rollback semantics and so checking this sort of thing there is unhelpful. (@iarna)
  • ff87938 #11735 Running npm install --save-dev will now update shrinkwrap file, but only if there already are devDependencies in it. (@szimek)
  • c00ca3a #13394 Check installability of modules from shrinkwrap, since modules that came into the tree vie shrinkwrap won't already have this information recorded in advance. (@iarna)


As part of the shrinkwrap push, there were also a lot of error-reporting improvements. Some to add more detail to error objects, others to fix bugs and inconsistencies.


  • 116b6c6 #13456 In lifecycle scripts, any node_modules/.bin existing in the hierarchy should be turned into an entry in the PATH environment variable. However, prior to this commit, it was splitting based on the string node_modules, rather than restricting it to only path portions like /node_modules/ or \node_modules\. So, a path containing an entry like my_node_modules would be improperly split. (@isaacs)
  • 0a28dd0 npm/fstream-npm#23 fstream-npm@1.2.0: Always ignore *.orig files, which are generated by git when using git mergetool, by default. (@zkat)
  • a3a2fb9 #13708 Always ignore *.orig files, which are generated by git when using git mergetool, by default. (@boneskull)