v4.0.0

Welcome to npm@4, friends!

This is our first semver major release since the release of npm@3 just over a year ago. Back then, @3 turned out to be a bit of a ground-shaking release, with a brand-new installer with significant structural changes to how npm set up your tree. This is the end of an era, in a way. npm@4 also marks the release when we move both npm@2 and npm@3 into maintenance: We will no longer be updating those release branches with anything except critical bugfixes and security patches.

While its predecessor had some pretty serious impact, npm@4 is expected to have a much smaller effect on your day-to-day use of npm. Over the past year, we've collected a handful of breaking changes that we wanted to get in which are only breaking under a strict semver interpretation (which we follow). Some of these are simple usability improvements, while others fix crashes and serious issues that required a major release to include.

We hope this release sees you well, and you can look forward to an accelerated release pace now that the CLI team is done focusing on sustaining work -- our Windows fixing and big bugs pushes -- and we can start focusing again on usability, features, and performance. Keep an eye out for npm@5 in Q1 2017, too: We're planning a major overhaul of shrinkwrap as well as various speed and usability fixes for that release. It's gonna be a fun ride. I promise. 😘

BRIEF OVERVIEW OF BREAKING CHANGES

The following breaking changes are included in this release:

• npm search rewritten to stream results, and no longer supports sorting.
• npm scripts no longer prepend the path of the node executable used to run npm before running scripts. A --scripts-prepend-node-path option has been added to configure this behavior.
• npat has been removed.
• prepublish has been deprecated, replaced by prepare. A prepublishOnly script has been temporarily added, which will only run on npm publish.
• npm outdated exits with exit code 1 if it finds any outdated packages.
• npm tag has been removed after a deprecation cycle. Use npm dist-tag.
• Partial shrinkwraps are no longer supported. npm-shrinkwrap.json is considered a complete installation manifest except for devDependencies.
• npm's default git branch is no longer master. We'll be using latest from now on.

SEARCH REWRITE (BREAKING)

Let's face it -- npm search simply doesn't work anymore. Apart from the fact that it grew slower over the years, it's reached a point where we can no longer fit the entire registry metadata in memory, and anyone who tries to use the command now sees a really awful memory overflow crash from node.

It's still going to be some time before the CLI, registry, and web team are able to overhaul npm search altogether, but until then, we've rewritten the previous npm search implementation to stream results on the fly, from both the search endpoint and a local cache. In absolute terms, you won't see a performance increase and this patch does come at the cost of sorting capabilities, but what it does do is start outputting results as it finds them. This should make the experience much better, overall, and we believe this is an acceptable band-aid until we have that search endpoint in place.

Incidentally, if you want a really nice search experience, we recommend checking out npms.io, which includes a handy-dandy npms-cli for command-line usage -- it's an npm search site that returns high-quality results quickly and is operated by members of the npm community.

• cfd43b4 2b8057b #13746 Stream search process end-to-end. (@zkat and @aredridel)
• 50f4ec8 70b4bc2 8fb470f ac3a6e0 bad54dd 87d504e #13746 Updated search-related tests. (@zkat)
• 3596de8 #13746 JSONStream@1.2.1 (@zkat)
• 4b09209 #13746 mississippi@1.2.0 (@zkat)
• b650b39 #13746 sorted-union-stream@2.1.3 (@zkat)

SCRIPT NODE PATH (BREAKING)

Thanks to some great with by @addaleax, we've addressed a fairly tricky issue involving the node process used by npm scripts.

Previously, npm would prefix the path of the node executable to the script's PATH. This had the benefit of making sure that the node process would be the same for both npm and scripts unless you had something like node-bin in your node_modules. And it turns out lots of people relied on this behavior being this way!

It turns out that this had some unintended consequences: it broke systems like nyc, but also completely broke/defeated things like rvm and virtualenv by often causing things that relied on them to fall back to the global system versions of ruby and python.

In the face of two perfectly valid, and used alternatives, we decided that the second case was much more surprising for users, and that we should err on the side of doing what those users expect. Anna put some hard work in and managed to put together a patch that changes npm's behavior such that we no longer prepend the node executable's path by default, and adds a new option, --scripts-prepend-node-path, to allow users who rely on this behavior to have it add the node path for them.

This patch also makes it so this feature is discoverable by people who might run into the first case above, by warning if the node executable is either missing or shadowed by another one in PATH. This warning can also be disabled with the --scripts-prepend-node-path option as needed.

• 3fb1eb3 6a7d375 378ae08 #13409 Add a --scripts-prepend-node-path option to configure whether npm prepends the current node executable's path to PATH. (@addaleax)
• 70b352c #13409 Change the default behaviour of npm to never prepending the current node executable’s directory to PATH but printing a warning in the cases in which it previously did. (@addaleax)

REMOVE npat (BREAKING)

Let's be real here -- almost no one knows this feature ever existed, and it's a vestigial feature of the days when the ideal for npm was to distribute full packages that could be directly developed on, even from the registry.

It turns out the npm community decided to go a different way: primarily publishing packages in a production-ready format, with no tests, build tools, etc. And so, we say goodbye to npat.

• e16c14a #14329 Remove the npat feature. (@iarna)

NEW prepare SCRIPT. prepublish DEPRECATED (BREAKING)

If there's anything that really seemed to confuse users, it's that the prepublish script ran when invoking npm install without any arguments.

Turns out many, many people really expected that it would only run on npm publish, even if it actually did what most people expected: prepare the package for publishing on the registry.

And so, we've added a prepare command that runs in the exact same cases where prepublish ran, and we've begun a deprecation cycle for prepublish itself only when run by npm install, which will now include a warning any time you use it that way.

We've also added a prepublishOnly script which will execute only when npm publish is invoked. Eventually, prepublish will stop executing on npm install, and prepublishOnly will be removed, leaving prepare and prepublish as two distinct lifecycles.

• 9b4a227 bc32078 #14290 Add prepare and prepublishOnly lifecyle events. (@othiym23)
• 52fdefd #14290 Warn when running prepublish on npm pack. (@othiym23)
• 4c2a948 [a55bd65](a55bd651284552b93f7d972a2...

v3.10.9

Hi everyone! This is the last of our monthly releases. We're going to give an every-two-weeks schedule a try starting with our next release. We'll reevaluate in a quarter, but we suspect that will be what we'll stick with. You might be wondering why we've been fiddling with the release cadence? Well, we've been trying to tune it to to minimize the overhead for our little team.

This is ALSO the ULTIMATE release of npm version 3. That's right, in just two weeks' time (October 20th for you fans of calendar time), our dear npm will be hitting the big 4.0.

DON'T PANIC

This is gonna be a much, MUCH smaller major version than 3.x was. Maybe even smaller than 2.x was. I can't tell you everything that'll be in there just yet, but at the very least it's going to have what's in our 4.x milestone, PLUS, the first steps in making prepublish work the way people expect it to.

NOW ABOUT THIS RELEASE

This release sees a whole slew of bug fixes. Notably a bunch of lifecycle fixes and a really important shrinkwrap fix.

LIFECYCLE FIXES

• d388f90 #13942 Fix current working directory while running shrinkwrap lifecycle scripts. Previously if you ran a shrinkwrap from another lifecycle script AND node_modules existed (and if you're running npm shrinkwrap it probably should) then npm would run the shrinkwrap lifecycle from the node_modules folder instead of the package folder. (@evocateur) (@iarna)
• c3b6cdf #13964 Fix bug where the uninstall lifecycles weren't being run when you reinstalled/updated an existing module. (@iarna)
• 72bb89c #13344 When running lifecycles use TMPDIR if it's writable and fall back to the current working directory if not. Previously we just assumed TMPDIR wouldn't be writable (as we might have been running as nobody and nobody on some systems can't write to TMPDIR). (@aaronjensen)

SHRINKWRAP GIT & TAGGED DEPENDENCY FIX

• 3b5eee0 #13941 Fix git and tagged dependency matching with shrinkwraps. Previously git and tag (ie foo@latest) dependencies installed from a shrinkwrap would always be flagged as invalid. (@iarna)

BUG FIXES

• bf3bd1e #14143 Fix bug in npm version where npm-shrinkwrap.json wouldn't be updated if you ran npm version from outside of your project root. (@lholmquist)
• 1089878 #13613 Log 'skipping action' as 'verbose' instead of 'warn'. This removes a lot of clutter when there are links in your node_modules. The long term plan is to entirely blind npm to what's inside links, which will make this code go away entirely. (@timoxley)
• 952f1e1 #13999 Fix a bug where setting bin to null in your package.json would result in npm crashing. (@IonicaBizau)
• fcf8b11 #14032 When using npm view, if you specified a version that didn't exist it would previously print undefined (even if you asked for JSON output). It now prints nothing in this situation. This brings npm@3's behavior in line with npm@2. (@roblg)
• 93c689f #14032 When using npm view --json with a version range that matches multiple versions we now return a list of all of the metadata for all of those versions. Previously we picked one and only returned that. This brings npm@3's behavior in line with npm@2. (@roblg)
• 2411728 #14045 Fix a Windows-only bug in the git tests. The tests had rather particular ideas about what arguments would be passed to git and on Windows they got this wrong. (@watilde)

DOCUMENTATION & MISC

• 30772cc #13904 Update package.json example to include GitHub branches. (@stevokk)
• f66876f #14010 Update the GitHub issue template to reflect Apple's change in name of its desktop operating system. (@AlexChesters)

DEPENDENCY UPDATES

• b3f9bf1 #13918 graceful-fs@4.1.9: Fix the uid must be an unsigned int bug that's been around forever but that npm started tickling in v3.10.8. (@addaleax) Also fixes wrapper to fs.readdir to actually pass through (rather than drop) optional arguments. (@isaacs)
• 9402ead isaacs/node-glob#293 glob@7.1.0: Add absolute option for match event. (@phated)
• 58b83db asap@2.0.5 (@kriskowal)
• 5707e6e sorted-object@2.0.1 (@domenic)
• 9d20910 request@2.75.0 (@simov)
• dea4848 path-is-inside@1.0.2 (@domenic)
• b3f3db5 opener@1.4.2 (@dominic)
• 6bb5f95 lockfile@1.0.2 (@isaacs)
• 13f7c0a config-chain@1.1.11 (@dominictarr)

v3.10.8

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!

SHRINKWRAP LEVEL UP

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)

INSTALLER ERROR REPORTING LEVEL UP

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.

• 2cdd713 Consistently set code on ETARGET when fetching package metadata if no compatible version is found. (@iarna)
• cabcd17 #13692 Include installer warning details at the verbose log level. (@iarna)
• 95a4044 dbb14c2 9994383 7417000 f45f85d e79cc1b 146ee39 #13692 Improve various bits of error reporting, adding more error information and some related refactoring. (@iarna)

MISCELLANEOUS BUGS LEVEL UP

• 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)

TOOLING LEVEL UP

• e1d7e6c Add helper for generating test skeletons. (@iarna)
• 4400b35 Fix fixture creation and cleanup in maketest. (@iarna)

DOCUMENTATION LEVEL UP

• 8eb9460 #13717 Document that npm link will link the files specified in the bin field of package.json to {prefix}/bin/{name}. (@legodude17)
• a66e5e9 #13682 Minor grammar fix in documentation for npm scripts. (@Ajedi32)
• 74b8043 #13655 Document line comment syntax for .npmrc. (@mdjasper)
• b352a84 #12438 Remind folks to use #!/usr/bin/env node in their bin scripts to make files executable directly. (@mxstbr)
• b82fd83 #13493 Document that the user config file can itself be configured either through the $NPM_CONFIG_USERCONFIG environment variable, or --userconfig command line flag. (@jasonkarns)
• 8a02699 #13911 Minor documentation reword and cleanup. (@othiym23)

DEPENDENCY LEVEL UP

• 2818fb0 glob@7.0.6 (@isaacs)
• d88ec81 graceful-fs@4.1.6 (@francescoinfante)
• 4727f86 lodash.clonedeep@4.5.0 (@jdalton)
• c347678 lodash.union@4.6.0 (@jdalton)
• 530bd4d lodash.uniq@4.5.0 (@jdalton)
• 483d56a lodash.without@4.4.0 (@jdalton)
• 6c934df inherits@2.0.3 (@isaacs)
• a65ed7c npm-registry-client@7.2.1 (@othiym23)
  • npm/npm-registry-client#142 Fix EventEmitter warning spam from error handlers on socket. (@addaleax)
  • npm/npm-registry-client#131 Adds support for streaming request bodies. (@aredridel)
  • Fixes #13656.
  • Dependency updates.
  • Documentation improvements.
• 2b88d62 npm/npmlog#34 npmlog@4.0.0: Allows creating log levels that are empty strings or 0 (@rwaldron)
• [242babb](https://github.co...

v2.15.11

On we go with our monthly release cadence! This week is pretty much all dependency updates and some documentation changes, as can be expected by now.

Note that npm@4 will almost certainly be released next month! It's not final what we'll end up doing as far as LTS support goes, but the current thinking is that, considering how small and resource-constrained our team is, support for npm@2 will be reduced to essentially maintenance, so we can better focus on npm@3 as the new LTS version (which will go into node@6), and npm@4 as our next main development version.

DOCUMENTATION UPDATES

• 8f71038 #13892 Update LICENSE file to match license on master. (@rvagg)
• e81b4f1 #12438 Remind folks to use #!/usr/bin/env node in their bin scripts to make files executable directly. (@mxstbr)
• f89789f #13655 Document line comment syntax for .npmrc. (@mdjasper)
• 5cd3abc #13493 Document that the user config file can itself be configured either through the $NPM_CONFIG_USERCONFIG environment variable, or --userconfig command line flag. (@jasonkarns)
• dd71ca0 #13911 Minor documentation reword and cleanup. (@othiym23)
• f7a320c #13682 Minor grammar fix in documentation for npm scripts. (@Ajedi32)
• e5cb5e8 #13717 Document that npm link will link the files specified in the bin field of package.json to {prefix}/bin/{name}. (@legodude17)

DEPENDENCY UPDATES

• 8bef026 graceful-fs@4.1.6 (@francescoinfante)
• 9f73f4a glob@7.0.6 (@isaacs)
• 5391b7e which@1.2.1 (@isaacs)
• 43bfec8 retry@0.10.0 (@tim-kos)
• 39305f1 readable-stream@2.1.5 (@calvinmetcalf)
• a5512fa once@1.4.0 (@zkochan)
• 06a208b npm-registry-client@7.2.1 (@othiym23)
  • npm/npm-registry-client#142 Fix EventEmitter warning spam from error handlers on socket. (@addaleax)
  • npm/npm-registry-client#131 Adds support for streaming request bodies. (@aredridel)
  • Fixes #13656.
  • Dependency updates.
  • Documentation improvements.
• 4f759be inherits@2.0.3 (@isaacs)
• 4258b76 tap@7.1.1 (@isaacs)

v3.10.7

v3.10.7 (2016-08-11)

Hi all, today's our first release coming out of the new monthly release cadence. See below for details. We're all recovered from conferences now and raring to go! We've got some pretty keen bug fixes and a bunch of documentation and dependency updates. It's hard to narrow it down to just a few, but of note are scoped packages in bundled dependencies, the preinstall lifecycle fix, the shrinkwrap and Git dependencies fix and the fix to a crasher involving cycles in development dependencies.

NEW RELEASE CADENCE

Releasing npm has been, for the most part, a very prominent part of our weekly process process. As part of our efforts to find the most effective ways to allocate our team's resources, we decided last month that we would try and slow our releases down to a monthly cadence, and see if we found ourselves with as much extra time and attention as we expected to have. Process experiments are useful for finding more effective ways to do our work, and we're at least going to keep doing this for a whole quarter, and then measure how well it worked out. It's entirely likely that we'll switch back to a more frequent cadence, specially if we find that the value that weekly cadence was providing the community is not worth sacrificing for a bit of extra time. Does this affect you significantly? Let us know!

SCOPED PACKAGES IN BUNDLED DEPENDENCIES

Prior to this release and v2.15.10, npm had ignored scoped modules found in bundleDependencies.

• 29cf56d #8614 Include scoped packages in bundled dependencies. (@forivall)

preinstall LIFECYCLE IN CURRENT PROJECT

• b7f13bc #13259 Run top level preinstall before installing dependencies (@palmerj3)

BETTER SHRINKWRAP WITH GIT DEPENDENCIES

• 0f7e319 #12718 Update outdated git dependencies found in shrinkwraps. Previously, if the module version was the same then no update would be completed even if the committish had changed. (@kossnocorp)

CYCLES IN DEVELOPMENT DEPENDENCIES NO LONGER CRASH

• 1691de6 #13327 Fix bug where cycles found in development dependencies could result in infinite recursion that resulted in crashes. (@iarna)

IMPROVE "NOT UPDATING LINKED MODULE" WARNINGS

• 1619871 #12893 Only warn about symlink update if version number differs The update-linked action outputs a warning that it needs to update the linked package, but can't, There is no need for the package to be updated if it is already at the correct version. This change does a check before logging the warning. (@DaveEmmerson)

MORE BUG FIXES

• 8f8d1b3 #11398 Fix bug where package.json files that contained a type property could cause crashes. type is not a package.json property that npm makes use of and having it should be (and now is) harmless. (@zkat)
• e7fa6c6 #13353 Add GIT_EXEC_PATH to Git environment whitelist. (@mhart)
• c23af21 #13626 Use HTTPS issues URL in the error message for type validation errors. (@watilde)

INCLUDE npm login IN COMMAND SUMMARY

• ab0c4b1 #13581 The login command has long been an alias for adduser. At the same time, there is an expectation not just of that particular word being something to look for, but of there being clear symmetry with logout. So it was a bit confusing when login didn't show up in npm help on a technicality. This seems like an acceptable exception to the rule that says "no aliases in npm help". (@zkat)

DOCUMENTATION

• e2d7e78 #13319 As Node.js 0.8 is no longer supported, remove mention of it from the README. (@watilde)
• c565d89 #13349 Updated the scripts documentation to explain the different between version and preversion. (@christophehurpeau)
• fa8f87f #10167 Clarify in scope documentation that npm@2 is required for scoped packages. (@danpaz)

DEPENDENCIES

• 124427e #8614 fstream-npm@1.1.1: Fixes bug with inclusion of scoped bundled dependencies. (@forivall)
• 7e0cdff #13497 graceful-fs@4.1.5: graceful-fs had a bug fix which fixes a problem (nodejs/node#7846) exposed by recent changes to Node.js. (@thefourtheye)
• 9b88cb8 #9984 request@2.74.0: Update request library to at least 2.73 to fix a bug where npm install would crash with Cannot read property 'emit' of null.
  Update request dependency tough-cookie to 2.3.0 to to address https://nodesecurity.io/advisories/130. Versions 0.9.7 through 2.2.2 contain a vulnerable regular expression that, under certain conditions involving long strings of semicolons in the "Set-Cookie" header, causes the event loop to block for excessive amounts of time. (@zarenner) (@stash-sfdc)
• bf78ce5 #13387 minimatch@3.0.3: Handle extremely long and terrible patterns more gracefully. There were some magic numbers that assumed that every extglob pattern starts and ends with a specific number of characters in the regular expression. Since !(||) patterns are a little bit more complicated, this led to creating an invalid regular expression and throwing. (@isaacs)
• 803e538 isaacs/rimraf#111 rimraf@2.5.4: Clarify assertions: cb is required, options are not. (@isaacs)
• a9f84ef lodash.without@4.2.0 (@jdalton)
• f59ff1c lodash.uniq@4.4.0 (@jdalton)
• 8cc027e lodash.union@4.5.0 (@jdalton)
• 0a6c1e4 lodash.without@4.3.0 (@jdalton)
• 4ab0181 lodash.clonedeep@4.4.1 (@jdalton)

v2.15.10

v2.15.10 (2016-08-11):

Hi all, today's our first release coming out of the new monthly release cadence. See below for details. We're all recovered from conferences now and raring to go! For LTS we see some bug fixes, documentation improvements and a host of dependency updates.

The most dramatic bug fix is probably the inclusion of scoped modules in bundled dependencies. Prior to this release and v3.10.7, npm had ignored scoped modules found in bundleDependencies entirely.

NEW RELEASE CADENCE

Releasing npm has been, for the most part, a very prominent part of our weekly process process. As part of our efforts to find the most effective ways to allocate our team's resources, we decided last month that we would try and slow our releases down to a monthly cadence, and see if we found ourselves with as much extra time and attention as we expected to have. Process experiments are useful for finding more effective ways to do our work, and we're at least going to keep doing this for a whole quarter, and then measure how well it worked out. It's entirely likely that we'll switch back to a more frequent cadence, specially if we find that the value that weekly cadence was providing the community is not worth sacrificing for a bit of extra time. Does this affect you significantly? Let us know!

WINDOWS CORNER CASES

• 405c404 #13023 Fixed a Windows issue with the cache where callbacks could be called more than once. (@zkat)
• bf348dc #13023 Fixed a Windows corner case with correct-mkdir where if SUDO_UID or SUDO_GID were set then we would try to chown things even though that can't work on Windows. (@zkat)

RACES IN THE CACHE

• 68f29f1 #12669 Ignore ENOENT errors on chownr while adding packages to cache. This change works around problems with race conditions and local packages. (@julianduque)

BETTER GIT ENVIRONMENT WHITELISTING

• 5e96566 #13358 Add GIT_EXEC_PATH to Git environment whitelist. (@mhart)

DOCUMENTATION

• 363e381 #13319 As Node.js 0.8 is no longer supported, remove mention of it from the README. (@watilde)
• e8fafa8 #10167 Clarify in scope documentation that npm@2 is required for scoped packages. (@danpaz)

DEPENDENCIES

• 66ef279 npm/fstream-npm#22 fstream@1.1.1: Always include NOTICE files now. Fix inclusion of scoped modules as bundled dependencies. (@kemitchell) (@forivall)
• fe8385b glob@7.0.5: Update minimatch dep for security fix. See the minimatch update below for details. (@isaacs)
• 51d49d2 isaacs/node-graceful-fs#71 graceful-fs@4.1.5: graceful-fs had a bug fix which fixes a problem (nodejs/node#7846) exposed by recent changes to Node.js. (@thefourtheye)
• 5c8f39d minimatch@3.0.3: Handle extremely long and terrible patterns more gracefully. There were some magic numbers that assumed that every extglob pattern starts and ends with a specific number of characters in the regular expression. Since !(||) patterns are a little bit more complicated, this led to creating an invalid regular expression and throwing. (@isaacs)
• d681e16 npm/npm-user-validate#9 npm-user-validate@0.1.5: Use correct, lower username length limit. (@aredridel)
• f918994 request@2.74.0: Update request dependency tough-cookie to 2.3.0 to to address https://nodesecurity.io/advisories/130. Versions 0.9.7 through 2.2.2 contain a vulnerable regular expression that, under certain conditions involving long strings of semicolons in the "Set-Cookie" header, causes the event loop to block for excessive amounts of time. (@stash-sfdc)
• 5540cc4 isaacs/rimraf#111 rimraf@2.5.4: Clarify assertions: cb is required, options are not. (@isaacs)
• 6357928 spdx-license-ids@1.2.2: New licenses synced from spdx.org. (@shinnn)

v3.10.6

v3.10.6 (2016-07-07)

This week we have a bunch of bug fixes for ya! A shrinkwrap regression introduced in 3.10.0, better lifecycle PATH behavior, improvements when working with registries other than registry.npmjs.org and a fix for hopefully the last don't print a progress bar over my interactive thingy bug.

SHRINKWRAP AND DEV DEPENDENCIES

The rewrite in 3.10.0 triggered a bug where dependencies of devDependencies would be included in your shrinkwrap even if you didn't request devDependencies.

• 2484529 #13308 Fix bug where deps of devDependencies would be incorrectly included in shrinkwraps. (@iarna)

BETTER PATH LIFECYCLE BEHAVIOR

We've been around the details on this one a few times in recent months and hopefully this will bring is to where we want to be.

• 81051a9 #12968 When running lifecycle scripts, only prepend directory containing the node binary to PATH if not already in PATH. (@segrey)

BETTER INTERACTIONS WITH THIRD PARTY REGISTRIES

• 071193c #10869 If the registry returns a list of versions some of which are invalid, skip those when picking a version to install. This can't happen with registry.npmjs.org as it will normalize versions published with it, but it can happen with other registries. (@gregersrygg)

ONE LAST TOO-MUCH-PROGRESS CORNER

• 1244cc1 #13305 Disable progress bar in npm edit and npm config edit. (@watilde)

HTML DOCS IMPROVEMENTS

• 58da923 #npm/npm Fix HTML character set declaration in generated HTML documentation. (@KenanY)
• d1f0bf4 #13250 Optimize png images using zopflipng. (@PeterDaveHello)

DEPENDENCY UPDATES (THAT MATTER)

• c7567e5 npm/npm-user-validate#9 npm-user-validate@0.1.5: Lower the username length limits to 214 from 576 to match registry.npmjs.org's limits. (@aredridel)
• 22802c9 #isaacs/rimraf rimraf@2.5.3: Fixes EPERM errors when running lstat on read-only directories. (@isaacs)
• ce6406f glob@7.0.5: Forces the use of minimatch to 3.0.2, which improved handling of long and complicated patterns. (@isaacs)

v3.10.5

v3.10.5 (2016-07-05)

This is a fix to this week's testing release to correct the update of node-gyp which somehow got mangled.

• ca97ce2 #13256 Fresh reinstall of node-gyp@3.4.0. (@zkat)

v3.10.4

Hey y'all! This release includes a bunch of fixes we've been working on as we continue on our big-bug push. There's still a lot of it left to do, but once this is done, things should just generally be more stable, installs should be more reliable and correct, and we'll be able to move on to more future work. We'll keep doing our best! 🙌

RACES AS WACKY AS REDLINE

Races are notoriously hard to squash, and tend to be some of the more common recurring bugs we see on the CLI. @julianduque did some pretty awesome sleuthing work to track down a cache race and helpfully submitted a patch. There were some related races in the same area that also got fixed at around the same time, mostly affecting Windows users.

• 2a37c97 #12669 #13023 The CLI is pretty aggressive about correcting permissions across the cache whenever it writes to it. This aggressiveness caused a couple of races where temporary cache files would get picked up by fs.readdir, and removed before chownr was called on them, causing ENOENT errors. While the solution might seem a bit hamfisted, it's actually perfectly safe and appropriate in this case to just ignore those resulting ENOENT errors. (@julianduque)
• ea018b9 #13023 If a user were to have SUDO_UID and SUDO_GID, they'd be able to get into a pretty weird state. This fixes that corner case. (@zkat)
• 703ca3a #13023 A missing return was causing chownr to be called on Windows, even though that's literally pointless, and causing crashes in the process, instead of short-circuiting. This was entirely dependent on which callback happened to be called first, and in some cases, the failing one would win the race. This should prevent this from happening in the future. (@zkat)
• 69267f4 #13023 Added tests to verify correct-mkdir race patch. (@zkat)
• e5f50ea #13023 Added tests to verify addLocal race patch. (@zkat)

SHRINKWRAP IS COMPLICATED BUT IT'S BETTER NOW

@iarna did some heroic hacking to refactor a bunch of shrinkwrap-related bits and fixed some resolution and pathing issues that were biting users. The code around that stuff got more readable/maintainable in the process, too!

• 346bba1 #13214 Resolve local dependencies in npm-shrinkwrap.json relative to the top of the tree. (@iarna)
• 4a67fdb #13213 If you run npm install modulename it should, if a npm-shrinkwrap.json is present, use the version found there. If not, it'll use the version found in your package.json, and failing that, use latest. This fixes a case where the first check was being bypassed because version resolution was being done prior to loading the shrinkwrap, and so checks to match the shrinkwrap version couldn't succeed. (@iarna)
• afa2133 #13214 Refactor shrinkwrap specifier lookup into shared function. (@iarna)
• 2820b56 #13214 Refactor operations in inflate-shrinkwrap.js into separate functions for added clarity. (@iarna)
• ee5bfb3 Fix Windows path issue in a shrinkwrap test. (@zkat)

OTHER BUGFIXES

• a11a7b2 #13212 Resolve local paths passed in through the command line relative to current directory, instead of relative to the package.json. (@iarna)

DEPENDENCY UPDATES

• 900a5b7 #13199 node-gyp@3.4.0: AIX, Visual Studio 2015, and logging improvements. Oh my~! (@rvagg)

DOCUMENTATION FIXES

• c6942a7 #13134 Fixed a few typos in CHANGELOG.md. (@watilde)
• e63d913 #13156 Fix old reference to doc/install in a source comment. (@sheerun)
• 099d23c #13113 #13189 Fixes a link to npm-tag(3) that was breaking to instead point to npm-dist-tag(1), as reported by @SimenB (@macdonst)

v2.15.9

What's this? An LTS release? Yes, that is indeed so. Small, as usual, and as LTSs should be, really, but a release nonetheless!

The star of the show is an updated node-gyp with some goodies. The rest is just docs and some CI stuff.

Happy hacking!

DEPENDENCY UPDATE!

• f9a07cc #13200 node-gyp@3.4.0: AIX, Visual Studio 2015, and logging improvements. Oh my~! (@rvagg)

CI TWEAKS

• bee83b8 Globally install rimraf on CI to make the LTS self-install work better. (@othiym23)
• 6b8c0ab This new Travis configuration only runs coverage checks against Node.js LTS, which speeds up all the other test runs. By, like, a lot. Also, the entire file has been extensively commented, so the next time we need to mess with it, we'll be able to better remember why all the weird bits are there. (@othiym23)

DOCUMENTATION FIXES

• 2c7a5be #13156 Fix old reference to doc/install in a source comment. (@sheerun)
• e1cf78c #13189 #13113 Fixes a link to npm-tag(3) that was breaking to instead point to npm-dist-tag(1), as reported by @SimenB (@macdonst)