node/deps/npm/CHANGELOG.md

v2.9.0 (2015-04-23):

This week was kind of a breather to concentrate on fixing up the tests on the multi-stage branch, and not mess with git issues for a little while. Unfortunately, There are now enough severe git issues that we'll probably have to spend another couple weeks tackling them. In the meantime, enjoy these two small features. They're just enough to qualify for a semver-minor bump:

NANOFEATURES

• 2799322 #7426 Include local modules in npm outdated and npm update. (@ArnaudRinquin)
• 2114862 #8014 The prefix used before the version on version tags is now configurable via tag-version-prefix. Be careful with this one and read the docs before using it. (@kkragenbrink)

OTHER MINOR TWEAKS

• 18ce0ec #3032 npm unpublish will now use the registry set in package.json, just like npm publish. This only applies, for now, when unpublishing the entire package, as unpublishing a single version requires the name be included on the command line and therefore doesn't read from package.json. (@watilde)
• 9ad2100 #8008 Once again, when considering what to install on npm install, include devDependencies. (@smikes)
• 5466260 #8003 Clarify the documentation around scopes to make it easier to understand how they support private packages. (@smikes)

DEPENDENCIES WILL NOT STOP UNTIL YOU ARE VERY SLEEPY

• faf65a7 init-package-json@1.4.2: If there are multiple validation errors and warnings, ensure they all get displayed (includes a rad new way of testing init-package-json contributed by @michaelnisi). (@MisumiRize)
• 7f10f38 editor@1.0.0: 1.0.0 is literally more than 0.1.0 (no change aside from version number). (@substack)
• 4979af3 #6805 npm-registry-client@6.3.3: Decode scoped package names sent by the registry so they look nicer. (@mmalecki)

v2.8.4 (2015-04-16):

This is the fourth release of npm this week, so it's mostly just landing a few small outstanding PRs on dependencies and some tiny documentation tweaks. npm@2.8.3 is where the real action is.

• ee2bd77 #7983 tar@2.1.0: Better error reporting in corrupted tar files, and add support for the fromBase flag (rescued from the dustbin of history by @deanmarano). (@othiym23)
• d8eee6c init-package-json@1.4.1: Add support for a default author, and only add scope to a package name once. (@othiym23)
• 4fc5d98 lru-cache@2.6.1: Small tweaks to cache value aging and entry counting that are irrelevant to npm. (@isaacs)
• 1fe5840 #7946 Make npm init text friendlier. (@sandfox)

v2.8.3 (2015-04-15):

TWO SMALL GIT TWEAKS

This is the last of a set of releases intended to ensure npm's git support is robust enough that we can stop working on it for a while. These fixes are small, but prevent a common crasher and clear up one of the more confusing error messages coming out of npm when working with repositories hosted on git.

• 387f889 #7961 Ensure that hosted git SSH URLs always have a valid protocol when stored in resolved fields in npm-shrinkwrap.json. (@othiym23)
• 394c2f5 Switch the order in which hosted Git providers are checked to git:, git+https:, then git+ssh: (from git:, git+ssh:, then git+https:) in an effort to go from most to least likely to succeed, to make for less confusing error message. (@othiym23)

v2.8.2 (2015-04-14):

PEACE IN OUR TIME

npm has been having an issue with CouchDB's web server since the release of io.js and Node.js 0.12.0 that has consumed a huge amount of my time to little visible effect. Sam Mikes picked up the thread from me, and after a lot of effort figured out that ultimately there are probably a couple problems with the new HTTP Agent keep-alive handling in new versions of Node. In addition, npm-registry-client was gratuitously sending a body along with a GET request which was triggering the bugs. Sam removed about 10 bytes from one file in npm-registry-client, and this problem, which has been bugging us for months, completely went away.

In conclusion, Sam Mikes is great, and anybody using a private registry hosted on CouchDB should thank him for his hard work. Also, thanks to the community at large for pitching in on this bug, which has been around for months now.

• 431c3bf #7699 npm-registry-client@6.3.2: Don't send body with HTTP GET requests when logging in. (@smikes)

v2.8.1 (2015-04-12):

CORRECTION: NPM'S GIT INTEGRATION IS DOING OKAY

A helpful bug report led to another round of changes to hosted-git-info, some additional test-writing, and a bunch of hands-on testing against actual private repositories. While the complexity of npm's git dependency handling is nearly fractal (because npm is very complex, and git is even more complex), it's feeling way more solid than it has for a while. We think this is a substantial improvement over what we had before, so give npm@2.8.1 a shot if you have particularly complex git use cases and let us know how it goes.

(NOTE: These changes mostly affect cloning and saving references to packages hosted in git repositories, and don't address some known issues with things like lifecycle scripts not being run on npm dependencies. Work continues on other issues that affect parity between git and npm registry packages.)

• 66377c6 #7872 hosted-git-info@2.1.2: Pass through credentials embedded in SSH and HTTPs git URLs. (@othiym23)
• 15efe12 #7872 Use the new version of hosted-git-info to pass along credentials embedded in git URLs. Test it. Test it a lot. (@othiym23)

SCOPED DEPENDENCIES AND PEER DEPENDENCIES: NOT QUITE REESE'S

Big thanks to @ewie for identifying an issue with how npm was handling peerDependencies that were implicitly installed from the package.json files of scoped dependencies. This will be a moot point with the release of npm@3, but until then, it's important that peerDependency auto-installation work as expected.

• b027319 #7920 Scoped packages with peerDependencies were installing the peerDependencies into the wrong directory. (@ewie)
• 649e31a #7920 Test peerDependency installs involving scoped packages using npm-package-arg instead of simple path tests, for consistency. (@othiym23)

MAKING IT EASIER TO WRITE NPM TESTS, VERSION 0.0.1

@iarna and I (@othiym23) have been discussing a candidate plan for improving npm's test suite, with the goal of making it easier for new contributors to get involved with npm by reducing the learning curve necessary to be able to write good tests for proposed changes. This is the first substantial piece of that effort. Here's what the commit message for ed7e249 had to say about this work:

It's too difficult for npm contributors to figure out what the conventional style is for tests. Part of the problem is that the documentation in CONTRIBUTING.md is inadequate, but another important factor is that the tests themselves are written in a variety of styles. One of the most notable examples of this is the fact that many tests use fixture directories to store precooked test scenarios and package.json files.

This had some negative consequences:

• tests weren't idempotent
• subtle dependencies between tests existed
• new tests get written in this deprecated style because it's not obvious that the style is out of favor
• it's hard to figure out why a lot of those directories existed, because they served a variety of purposes, so it was difficult to tell when it was safe to remove them

All in all, the fixture directories were a major source of technical debt, and cleaning them up, while time-consuming, makes the whole test suite much more approachable, and makes it more likely that new tests written by outside contributors will follow a conventional style. To support that, all of the tests touched by this changed were cleaned up to pass the standard style checker.

And here's a little extra context from a comment I left on #7929:

One of the other things that encouraged me was looking at this presentation on technical debt from Pycon 2015, especially slide 53, which I interpreted in terms of difficulty getting new contributors to submit patches to an OSS project like npm. npm has a long ways to go, but I feel good about this change.

• ed7e249 #7929 Eliminate fixture directories from test/tap, leaving each test self-contained. (@othiym23)
• 4928d30 #7929 Move fixture files from test/tap/* to test/fixtures. (@othiym23)
• e925deb #7929 Tweak the run scripts to stop slaughtering the CPU on doc rebuild. (@othiym23)
• 65bf7cf #7923 Use an alias of scripts and run-scripts in npm run test-all (@watilde)
• 756a3fb #7923 Sync timeout time of npm run-script test-all to be the same as test and tap scripts. (@watilde)
• 8299b5f Set a timeout for tap tests for npm run-script test-all. (@othiym23)

THE EVER-BEATING DRUM OF DEPENDENCY UPDATES

• d90d0b9 #7924 Remove child-process-close, as it was included for Node 0.6 compatibility, and npm no longer supports 0.6. (@robertkowalski)
• 16427c1 lru-cache@2.5.2: More accurate updating of expiry times when maxAge is set. (@isaacs)
• 03cce83 nock@1.6.0: Mocked network error handling. (@pgte)
• f93b1f0 glob@5.0.5: Use path-is-absolute polyfill, allowing newer Node.js and io.js versions to use path.isAbsolute(). (@sindresorhus)
• a70d694 request@2.55.0: Bug fixes and simplification. (@simov)
• 2aecc6f columnify@1.5.1: Switch to using babel from 6to5. (@timoxley)

v2.8.0 (2015-04-09):

WE WILL NEVER BE DONE FIXING NPM'S GIT SUPPORT

If you look at the last release's release notes, you will note that they confidently assert that it's perfectly OK to force all GitHub URLs through the same git: -> git+ssh: fallback flow for cloning. It turns out that many users depend on git+https: URLs in their build environments because they use GitHub auth tokens instead of SSH keys. Also, in some cases you just want to be able to explicitly say how a given dependency should be cloned from GitHub.

Because of the way we resolved the inconsistency in GitHub shorthand handling before, this turned out to be difficult to work around. So instead of hacking around it, we completely redid how git is handled within npm and its attendant packages. Again. This time, we changed things so that normalize-package-data and read-package-json leave more of the git logic to npm itself, which makes handling shorthand syntax consistently much easier, and also allows users to resume using explicit, fully-qualified git URLs without npm messing with them.

Here's a summary of what's changed:

• Instead of converting the GitHub shorthand syntax to a git+ssh:, git:, or git+https: URL and saving that, save the shorthand itself to package.json.
• If presented with shortcuts, try cloning via the git protocol, SSH, and HTTPS (in that order).
• No longer prompt for credentials -- it didn't work right with the spinner, and wasn't guaranteed to work anyway. We may experiment with doing this a better way in the future. Users can override this by setting GIT_ASKPASS in their environment if they want to experiment with interactive cloning, but should also set --no-spin on the npm command line (or run npm config set spin=false).
• EXPERIMENTAL FEATURE: Add support for github:, gist:, bitbucket:, and gitlab: shorthand prefixes. GitHub shortcuts will continue to be normalized to org/repo instead of being saved as github:org/repo, but gitlab:, gist:, and bitbucket: prefixes will be used on the command line and from package.json. BE CAREFUL WITH THIS. package.json files published with the new shorthand syntax can only be read by npm@2.8.0 and later, and this feature is mostly meant for playing around with it. If you want to save git dependencies in a form that older versions of npm can read, use --save-exact, which will save the git URL and resolved commit hash of the head of the branch in a manner similar to the way that --save-exact pins versions for registry dependencies. This is documented (so check npm help install for details), but we're not going to make a lot of noise about it until it has a chance to bake in a little more.

It is @othiym23's sincere hope that this will resolve all of the inconsistencies users were seeing with GitHub and git-hosted packages, but given the level of change here, that may just be a fond wish. Extra testing of this change is requested.

• 6b0f588 #7867 Use git shorthand and git URLs as presented by user. Support new hosted-git-info shortcut syntax. Save shorthand in package.json. Try cloning via git:, git+ssh:, and git+https:, in that order, when supported by the underlying hosting provider. (@othiym23)
• 75d4267 #7867 Document new GitHub, GitHub gist, Bitbucket, and GitLab shorthand syntax. (@othiym23)
• 7d92c75 #7867 When --save-exact is used with git shorthand or URLs, save the fully-resolved URL, with branch name resolved to the exact hash for the commit checked out. (@othiym23)
• 9220e59 #7867 Ensure that non-prefixed and non-normalized GitHub shortcuts are saved to package.json. (@othiym23)
• dd398e9 #7867 hosted-git-info@2.1.1: Ensure that gist: shorthand survives being round-tripped through package.json. (@othiym23)
• 33d1420 #7867 hosted-git-info@2.1.0: Add support for auth embedded directly in git URLs. (@othiym23)
• 23a1d5a #7867 hosted-git-info@2.0.2: Make it possible to determine in which form a hosted git URL was passed. (@iarna)
• eaf75ac #7867 normalize-package-data@2.0.0: Normalize GitHub specifiers so they pass through shortcut syntax and preserve explicit URLs. (@iarna)
• 95e0535 #7867 npm-package-arg@4.0.0: Add git URL and shortcut to hosted git spec and use hosted-git-info@2.0.2. (@iarna)
• a808926 #7867 realize-package-specifier@3.0.0: Use npm-package-arg@4.0.0 and test shortcut specifier behavior. (@iarna)
• 6dd1e03 #7867 init-package-json@1.4.0: Allow dependency on read-package-json@2.0.0. (@iarna)
• 63254bb #7867 read-installed@4.0.0: Use read-package-json@2.0.0. (@iarna)
• 254b887 #7867 read-package-json@2.0.0: Use normalize-package-data@2.0.0. (@iarna)
• 0b9f8be #7867 npm-registry-client@6.3.0: Mark compatibility with normalize-package-data@2.0.0 and npm-package-arg@4.0.0. (@iarna)
• f40ecaa #7867 Extract a common method to use when cloning git repos for testing. (@othiym23)

TEST FIXES FOR NODE 0.8

npm continues to get closer to being completely green on Travis for Node 0.8.

• 26d36e9 #7842 When spawning child processes, map exit code 127 to ENOENT so Node 0.8 handles child process failures the same as later versions. (@SonicHedgehog)
• 54cd895 #7842 Node 0.8 requires -e with -p when evaluating snippets; fix test. (@SonicHedgehog)

SMALL FIX AND DOC TWEAK

• 20e9003 tar@2.0.1: Fix regression where relative symbolic links within an extraction root that pointed within an extraction root would get normalized to absolute symbolic links. (@isaacs)
• 2ef8898 #7879 Better document that npm publish --tag=foo will not set latest to that version. (@linclark)

v2.7.6 (2015-04-02):

GIT MEAN, GIT TUFF, GIT ALL THE WAY AWAY FROM MY STUFF

Part of the reason that we're reluctant to take patches to how npm deals with git dependencies is that every time we touch the git support, something breaks. The last few releases are a case in point. npm@2.7.4 completely broke installing private modules from GitHub, and npm@2.7.5 fixed them at the cost of logging a misleading error message that caused many people to believe that their dependencies hadn't been successfully installed when they actually had been.

This all started from a desire to ensure that GitHub shortcut syntax is being handled correctly. The correct behavior is for npm to try to clone all dependencies on GitHub (whether they're specified with the GitHub organization/repository shortcut syntax or not) via the plain git: protocol first, and to fall back to using git+ssh: if git: doesn't work. Previously, sometimes npm would use git: and git+ssh: in some cases (most notably when using GitHub shortcut syntax on the command line), and use git+https: in others (when the GitHub shortcut syntax was present in package.json). This led to subtle and hard-to-understand inconsistencies, and we're glad that as of npm@2.7.6, we've finally gotten things to where they were before we started, only slightly more consistent overall.

We are now going to go back to our policy of being extremely reluctant to touch the code that handles Git dependencies.

• b747593 #7630 Don't automatically log all git failures as errors. maybeGithub needs to be able to fail without logging to support its fallback logic. (@othiym23)
• cd67a0d #7829 When fetching a git remote URL, handle failures gracefully (without assuming standard output exists). (@othiym23)
• 637c7d1 #7829 When fetching a git remote URL, handle failures gracefully (without assuming standard error exists). (@othiym23)

OTHER SIGNIFICANT FIXES

• 78005eb #7743 Always quote arguments passed to npm run-script. This allows build systems and the like to safely escape glob patterns passed as arguments to run-scripts with `npm run-script