deps: upgrade npm to 2.0.0

1 files changed, 91 insertions, 138 deletions

diff --git a/deps/npm/man/man1/npm-shrinkwrap.1 b/deps/npm/man/man1/npm-shrinkwrap.1
index 2a053a5b0..e154851b2 100644
--- a/deps/npm/man/man1/npm-shrinkwrap.1
+++ b/deps/npm/man/man1/npm-shrinkwrap.1
@@ -1,44 +1,37 @@
-.\" Generated with Ronnjs 0.3.8
-.\" http://github.com/kapouer/ronnjs/
-.
 .TH "NPM\-SHRINKWRAP" "1" "September 2014" "" ""
-.
 .SH "NAME"
-\fBnpm-shrinkwrap\fR \-\- Lock down dependency versions
-.
-.SH "SYNOPSIS"
-.
-.nf
+\fBnpm-shrinkwrap\fR \- Lock down dependency versions
+.SH SYNOPSIS
+.P
+.RS 2
+.EX
 npm shrinkwrap
-.
-.fi
-.
-.SH "DESCRIPTION"
-This command locks down the versions of a package\'s dependencies so
+.EE
+.RE
+.SH DESCRIPTION
+.P
+This command locks down the versions of a package's dependencies so
 that you can control exactly which versions of each dependency will be
 used when your package is installed\. The "package\.json" file is still
 required if you want to use "npm install"\.
-.
 .P
-By default, "npm install" recursively installs the target\'s
+By default, "npm install" recursively installs the target's
 dependencies (as specified in package\.json), choosing the latest
-available version that satisfies the dependency\'s semver pattern\. In
+available version that satisfies the dependency's semver pattern\. In
 some situations, particularly when shipping software where each change
-is tightly managed, it\'s desirable to fully specify each version of
+is tightly managed, it's desirable to fully specify each version of
 each dependency recursively so that subsequent builds and deploys do
 not inadvertently pick up newer versions of a dependency that satisfy
 the semver pattern\. Specifying specific semver patterns in each
-dependency\'s package\.json would facilitate this, but that\'s not always
+dependency's package\.json would facilitate this, but that's not always
 possible or desirable, as when another author owns the npm package\.
-It\'s also possible to check dependencies directly into source control,
+It's also possible to check dependencies directly into source control,
 but that may be undesirable for other reasons\.
-.
 .P
 As an example, consider package A:
-.
-.IP "" 4
-.
-.nf
+.P
+.RS 2
+.EX
 {
   "name": "A",
   "version": "0\.1\.0",
@@ -46,17 +39,13 @@ As an example, consider package A:
     "B": "<0\.1\.0"
   }
 }
-.
-.fi
-.
-.IP "" 0
-.
+.EE
+.RE
 .P
 package B:
-.
-.IP "" 4
-.
-.nf
+.P
+.RS 2
+.EX
 {
   "name": "B",
   "version": "0\.0\.1",
@@ -64,83 +53,62 @@ package B:
     "C": "<0\.1\.0"
   }
 }
-.
-.fi
-.
-.IP "" 0
-.
+.EE
+.RE
 .P
 and package C:
-.
-.IP "" 4
-.
-.nf
+.P
+.RS 2
+.EX
 {
   "name": "C,
   "version": "0\.0\.1"
 }
-.
-.fi
-.
-.IP "" 0
-.
+.EE
+.RE
 .P
 If these are the only versions of A, B, and C available in the
 registry, then a normal "npm install A" will install:
-.
-.IP "" 4
-.
-.nf
+.P
+.RS 2
+.EX
 A@0\.1\.0
 `\-\- B@0\.0\.1
     `\-\- C@0\.0\.1
-.
-.fi
-.
-.IP "" 0
-.
+.EE
+.RE
 .P
 However, if B@0\.0\.2 is published, then a fresh "npm install A" will
 install:
-.
-.IP "" 4
-.
-.nf
+.P
+.RS 2
+.EX
 A@0\.1\.0
 `\-\- B@0\.0\.2
     `\-\- C@0\.0\.1
-.
-.fi
-.
-.IP "" 0
-.
+.EE
+.RE
 .P
-assuming the new version did not modify B\'s dependencies\. Of course,
+assuming the new version did not modify B's dependencies\. Of course,
 the new version of B could include a new version of C and any number
 of new dependencies\. If such changes are undesirable, the author of A
-could specify a dependency on B@0\.0\.1\. However, if A\'s author and B\'s
-author are not the same person, there\'s no way for A\'s author to say
+could specify a dependency on B@0\.0\.1\. However, if A's author and B's
+author are not the same person, there's no way for A's author to say
 that he or she does not want to pull in newly published versions of C
-when B hasn\'t changed at all\.
-.
+when B hasn't changed at all\.
+.P
+In this case, A's author can run
 .P
-In this case, A\'s author can run
-.
-.IP "" 4
-.
-.nf
+.RS 2
+.EX
 npm shrinkwrap
-.
-.fi
-.
-.IP "" 0
-.
+.EE
+.RE
 .P
 This generates npm\-shrinkwrap\.json, which will look something like this:
-.
-.IP "" 4
-.
-.nf
+.P
+.RS 2
+.EX
 {
   "name": "A",
   "version": "0\.1\.0",
@@ -155,79 +123,68 @@ This generates npm\-shrinkwrap\.json, which will look something like this:
     }
   }
 }
-.
-.fi
-.
-.IP "" 0
-.
+.EE
+.RE
 .P
 The shrinkwrap command has locked down the dependencies based on
-what\'s currently installed in node_modules\.  When "npm install"
+what's currently installed in node_modules\.  When "npm install"
 installs a package with a npm\-shrinkwrap\.json file in the package
 root, the shrinkwrap file (rather than package\.json files) completely
 drives the installation of that package and all of its dependencies
 (recursively)\.  So now the author publishes A@0\.1\.0, and subsequent
 installs of this package will use B@0\.0\.1 and C@0\.1\.0, regardless the
-dependencies and versions listed in A\'s, B\'s, and C\'s package\.json
+dependencies and versions listed in A's, B's, and C's package\.json
 files\.
-.
-.SS "Using shrinkwrapped packages"
+.SS Using shrinkwrapped packages
+.P
 Using a shrinkwrapped package is no different than using any other
 package: you can "npm install" it by hand, or add a dependency to your
 package\.json file and "npm install" it\.
-.
-.SS "Building shrinkwrapped packages"
+.SS Building shrinkwrapped packages
+.P
 To shrinkwrap an existing package:
-.
-.IP "1" 4
+.RS 0
+.IP 1. 3
 Run "npm install" in the package root to install the current
 versions of all dependencies\.
-.
-.IP "2" 4
+.IP 2. 3
 Validate that the package works as expected with these versions\.
-.
-.IP "3" 4
+.IP 3. 3
 Run "npm shrinkwrap", add npm\-shrinkwrap\.json to git, and publish
 your package\.
-.
-.IP "" 0
-.
+
+.RE
 .P
 To add or update a dependency in a shrinkwrapped package:
-.
-.IP "1" 4
+.RS 0
+.IP 1. 3
 Run "npm install" in the package root to install the current
 versions of all dependencies\.
-.
-.IP "2" 4
+.IP 2. 3
 Add or update dependencies\. "npm install" each new or updated
 package individually and then update package\.json\.  Note that they
 must be explicitly named in order to be installed: running \fBnpm
 install\fR with no arguments will merely reproduce the existing
 shrinkwrap\.
-.
-.IP "3" 4
+.IP 3. 3
 Validate that the package works as expected with the new
 dependencies\.
-.
-.IP "4" 4
+.IP 4. 3
 Run "npm shrinkwrap", commit the new npm\-shrinkwrap\.json, and
 publish your package\.
-.
-.IP "" 0
-.
+
+.RE
 .P
 You can use npm help outdated to view dependencies with newer versions
 available\.
-.
-.SS "Other Notes"
-A shrinkwrap file must be consistent with the package\'s package\.json
+.SS Other Notes
+.P
+A shrinkwrap file must be consistent with the package's package\.json
 file\. "npm shrinkwrap" will fail if required dependencies are not
 already installed, since that would result in a shrinkwrap that
-wouldn\'t actually work\. Similarly, the command will fail if there are
+wouldn't actually work\. Similarly, the command will fail if there are
 extraneous packages (not referenced by package\.json), since that would
 indicate that package\.json is not correct\.
-.
 .P
 Since "npm shrinkwrap" is intended to lock down your dependencies for
 production use, \fBdevDependencies\fR will not be included unless you
@@ -235,31 +192,27 @@ explicitly set the \fB\-\-dev\fR flag when you run \fBnpm shrinkwrap\fR\|\.  If
 installed \fBdevDependencies\fR are excluded, then npm will print a
 warning\.  If you want them to be installed with your module by
 default, please consider adding them to \fBdependencies\fR instead\.
-.
 .P
-If shrinkwrapped package A depends on shrinkwrapped package B, B\'s
+If shrinkwrapped package A depends on shrinkwrapped package B, B's
 shrinkwrap will not be used as part of the installation of A\. However,
-because A\'s shrinkwrap is constructed from a valid installation of B
-and recursively specifies all dependencies, the contents of B\'s
-shrinkwrap will implicitly be included in A\'s shrinkwrap\.
-.
-.SS "Caveats"
+because A's shrinkwrap is constructed from a valid installation of B
+and recursively specifies all dependencies, the contents of B's
+shrinkwrap will implicitly be included in A's shrinkwrap\.
+.SS Caveats
+.P
 If you wish to lock down the specific bytes included in a package, for
 example to have 100% confidence in being able to reproduce a
 deployment or build, then you ought to check your dependencies into
 source control, or pursue some other mechanism that can verify
 contents rather than versions\.
-.
-.SH "SEE ALSO"
-.
-.IP "\(bu" 4
+.SH SEE ALSO
+.RS 0
+.IP \(bu 2
 npm help install
-.
-.IP "\(bu" 4
+.IP \(bu 2
 npm help 5 package\.json
-.
-.IP "\(bu" 4
+.IP \(bu 2
 npm help ls
-.
-.IP "" 0
+
+.RE