deps: upgrade to npm 2.13.4

PR-URL: nodejs/node-v0.x-archive#25825
Reviewed-By: James M Snell <[email protected]>

Author: zkat

deps/npm/.travis.yml

@@ -8,7 +8,7 @@ env:
   - DEPLOY_VERSION=testing
 before_install:
   - "npm config set spin false"
-  - "npm install -g npm/npm"
+  - "npm install -g npm/npm#2.x"
   - "sudo mkdir -p /var/run/couchdb"
 script: "npm run-script test-all"
 notifications:

deps/npm/AUTHORS

@@ -288,3 +288,17 @@ Cedric Nelson <[email protected]>
 Kat Marchán <[email protected]>
 Andrew <[email protected]>
 Eduardo Pinho <[email protected]>
+Rachel Hutchison <[email protected]>
+Ryan Temple <[email protected]>
+Eugene Sharygin <[email protected]>
+Nick Heiner <[email protected]>
+James Talmage <[email protected]>
+jane arc <[email protected]>
+Joseph Dykstra <[email protected]>
+Joshua Egan <[email protected]>
+Thomas Cort <[email protected]>
+Thaddee Tyl <[email protected]>
+Steve Klabnik <[email protected]>
+Andrew Murray <[email protected]>
+Stephan Bönnemann <[email protected]>
+Kyle M. Tarplee <[email protected]>

deps/npm/CHANGELOG.md

@@ -0,0 +1,14 @@
+npm-ping(3) -- Ping npm registry
+================================
+
+## SYNOPSIS
+
+    npm.registry.ping(registry, options, function (er, pong))
+
+## DESCRIPTION
+
+Attempts to connect to the given registry, returning a `pong`
+object with various metadata if it succeeds.
+
+This function is primarily useful for debugging connection issues
+to npm registries.

deps/npm/doc/api/npm-ping.md

@@ -166,11 +166,24 @@ after packing it up into a tarball (b).
     `git+https`.  If no `<commit-ish>` is specified, then `master` is
     used.
 
+    The following git environment variables are recognized by npm and will be added
+    to the environment when running git:
+
+    * `GIT_ASKPASS`
+    * `GIT_PROXY_COMMAND`
+    * `GIT_SSH`
+    * `GIT_SSH_COMMAND`
+    * `GIT_SSL_CAINFO`
+    * `GIT_SSL_NO_VERIFY`
+
+    See the git man page for details.
+
     Examples:
 
-          git+ssh://[email protected]:npm/npm.git#v1.0.27
-          git+https://[email protected]/npm/npm.git
-          git://github.com/npm/npm.git#v1.0.27
+          npm install git+ssh://[email protected]:npm/npm.git#v1.0.27
+          npm install git+https://[email protected]/npm/npm.git
+          npm install git://github.com/npm/npm.git#v1.0.27
+          GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://[email protected]:npm/npm.git
 
 * `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
 * `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:

deps/npm/doc/cli/npm-install.md

@@ -0,0 +1,16 @@
+npm-ping(1) -- Ping npm registry
+================================
+
+## SYNOPSIS
+
+    npm ping [--registry <registry>]
+
+## DESCRIPTION
+
+Ping the configured or given npm registry and verify authentication.
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

deps/npm/doc/cli/npm-ping.md

@@ -33,8 +33,11 @@ In addition to the shell's pre-existing `PATH`, `npm run` adds
 `node_modules/.bin` to the `PATH` provided to scripts. Any binaries provided by
 locally-installed dependencies can be used without the `node_modules/.bin`
 prefix. For example, if there is a `devDependency` on `tap` in your package,
-you should write `"scripts": {"test": "tap test/\*.js"}` instead of `"scripts":
-{"test": "node_modules/.bin/tap test/\*.js"}` to run your tests.
+you should write:
+
+    "scripts": {"test": "tap test/\*.js"}
+
+instead of `"scripts": {"test": "node_modules/.bin/tap test/\*.js"}` to run your tests.
 
 ## SEE ALSO
 

deps/npm/doc/cli/npm-run-script.md

@@ -11,14 +11,15 @@ Run this in a package directory to bump the version and write the new
 data back to `package.json` and, if present, `npm-shrinkwrap.json`.
 
 The `newversion` argument should be a valid semver string, *or* a
-valid second argument to semver.inc (one of "patch", "minor", "major",
-"prepatch", "preminor", "premajor", "prerelease"). In the second case,
+valid second argument to semver.inc (one of `patch`, `minor`, `major`,
+`prepatch`, `preminor`, `premajor`, `prerelease`). In the second case,
 the existing version will be incremented by 1 in the specified field.
 
-If run in a git repo, it will also create a version commit and tag, and fail if
-the repo is not clean.  This behavior is controlled by `git-tag-version` (see
-below), and can be disabled on the command line by running `npm
---no-git-tag-version version`
+If run in a git repo, it will also create a version commit and tag.
+This behavior is controlled by `git-tag-version` (see below), and can
+be disabled on the command line by running `npm --no-git-tag-version version`.
+It will fail if the working directory is not clean, unless the `--force`
+flag is set.
 
 If supplied with `--message` (shorthand: `-m`) config option, npm will
 use it as a commit message when creating a version commit.  If the
@@ -40,13 +41,35 @@ in your git config for this to work properly.  For example:
 
     Enter passphrase:
 
-If "preversion", "version", "postversion" in the "scripts" property of
-the package.json, it will execute by running `npm version`. preversion
-and version ware executed before bump the package version, postversion
-was executed after bump the package version. For example to run `npm version`
-after passed all test:
-
-    "scripts": { "preversion": "npm test" }
+If `preversion`, `version`, or `postversion` are in the `scripts` property of
+the package.json, they will be executed as part of running `npm version`.
+
+The exact order of execution is as follows:
+  1. Check to make sure the git working directory is clean before we get started.
+     Your scripts may add files to the commit in future steps.
+     This step is skipped if the `--force` flag is set.
+  2. Run the `preversion` script. These scripts have access to the old `version` in package.json.
+     A typical use would be running your full test suite before deploying.
+     Any files you want added to the commit should be explicitly added using `git add`.
+  3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc).
+  4. Run the `version` script. These scripts have access to the new `version` in package.json
+     (so they can incorporate it into file headers in generated files for example).
+     Again, scripts should explicitly add generated files to the commit using `git add`.
+  5. Commit and tag.
+  6. Run the `postversion` script. Use it to clean up the file system or automatically push
+     the commit and/or tag.
+
+Take the following example:
+
+    "scripts": {
+      "preversion": "npm test",
+      "version": "npm run build && git add -A dist",
+      "postversion": "git push && git push --tags && rm -rf build/temp"
+    }
+
+This runs all your tests, and proceeds only if they pass. Then runs your `build` script, and
+adds everything in the `dist` directory to the commit. After the commit, it pushes the new commit
+and tag up to the server, and deletes the `build/temp` directory.
 
 ## CONFIGURATION
 

deps/npm/doc/cli/npm-version.md

@@ -52,6 +52,9 @@ running npm in.  It has no effect when your module is published.  For
 example, you can't publish a module that forces itself to install
 globally, or in a different location.
 
+Additionally, this file is not read in global mode, such as when running
+`npm install -g`.
+
 ### Per-user config file
 
 `$HOME/.npmrc` (or the `userconfig` param, if set in the environment

deps/npm/doc/files/npmrc.md

@@ -115,9 +115,9 @@ expression syntax version 2.0 string](http://npmjs.com/package/spdx), like this:
 If you are using a license that hasn't been assigned an SPDX identifier, or if
 you are using a custom license, use the following valid SPDX expression:
 
-    { "license" : "LicenseRef-LICENSE" }
+    { "license" : "SEE LICENSE IN <filename>" }
 
-Then include a LICENSE file at the top level of the package.
+Then include a file named `<filename>` at the top level of the package.
 
 Some old packages used license objects or a "licenses" property containing an
 array of license objects:
@@ -147,6 +147,13 @@ Those styles are now deprecated. Instead, use SPDX expressions, like this:
 
     { "license": "(MIT OR Apache-2.0)" }
 
+Finally, if you do not wish to grant others the right to use a private or
+unpublished package under any terms:
+
+    { "license": "UNLICENSED"}
+
+Consider also setting `"private": true` to prevent accidental publication.
+
 ## people fields: author, contributors
 
 The "author" is one person.  "contributors" is an array of people.  A "person"
@@ -176,6 +183,26 @@ which will keep files from being included, even if they would be picked
 up by the files array.  The ".npmignore" file works just like a
 ".gitignore".
 
+Certain files are always included, regardless of settings:
+
+* `package.json`
+* `README` (and its variants)
+* `CHANGELOG` (and its variants)
+* `LICENSE` / `LICENCE`
+
+Conversely, some files are always ignored:
+
+* `.git`
+* `CVS`
+* `.svn`
+* `.hg`
+* `.lock-wscript`
+* `.wafpickle-N`
+* `*.swp`
+* `.DS_Store`
+* `._*`
+* `npm-debug.log`
+
 ## main
 
 The main field is a module ID that is the primary entry point to your program.
@@ -276,10 +303,13 @@ with the lib folder in any way, but it's useful meta info.
 
 ### directories.bin
 
-If you specify a `bin` directory, then all the files in that folder will
-be added as children of the `bin` path.
+If you specify a `bin` directory in `directories.bin`, all the files in
+that folder will be added.
 
-If you have a `bin` path already, then this has no effect.
+Because of the way the `bin` directive works, specifying both a
+`bin` path and setting `directories.bin` is an error. If you want to
+specify individual files, use `bin`, and for all the files in an
+existing `bin` directory, use `directories.bin`.
 
 ### directories.man
 
@@ -660,13 +690,13 @@ param at publish-time.
 
 ## publishConfig
 
-This is a set of config values that will be used at publish-time.  It's
-especially handy if you want to set the tag or registry, so that you can
-ensure that a given package is not tagged with "latest" or published to
-the global public registry by default.
+This is a set of config values that will be used at publish-time. It's
+especially handy if you want to set the tag, registry or access, so that
+you can ensure that a given package is not tagged with "latest", published
+to the global public registry or that a scoped module is private by default.
 
-Any config values can be overridden, but of course only "tag" and
-"registry" probably matter for the purposes of publishing.
+Any config values can be overridden, but of course only "tag", "registry" and
+"access" probably matter for the purposes of publishing.
 
 See `npm-config(7)` to see the list of config options that can be
 overridden.