deps: upgrade npm to 5.3.0

PR-URL: https://github.com/nodejs/node/pull/14235
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: James M Snell <jasnell@gmail.com>

12 files changed, 343 insertions, 36 deletions

diff --git a/deps/npm/doc/cli/npm-config.md b/deps/npm/doc/cli/npm-config.md
index 5aecb2c3ac..aad9e0dffe 100644
--- a/deps/npm/doc/cli/npm-config.md
+++ b/deps/npm/doc/cli/npm-config.md
@@ -6,7 +6,7 @@ npm-config(1) -- Manage the npm configuration files
     npm config set <key> <value> [-g|--global]
     npm config get <key>
     npm config delete <key>
-    npm config list
+    npm config list [-l]
     npm config edit
     npm get <key>
     npm set <key> <value> [-g|--global]
@@ -48,7 +48,7 @@ Echo the config value to stdout.
 
     npm config list
 
-Show all the config settings.
+Show all the config settings. Use `-l` to also show defaults.
 
 ### delete
 
diff --git a/deps/npm/doc/cli/npm-install.md b/deps/npm/doc/cli/npm-install.md
index 44cb68792b..74e5e04bca 100644
--- a/deps/npm/doc/cli/npm-install.md
+++ b/deps/npm/doc/cli/npm-install.md
@@ -343,6 +343,9 @@ being installed.
 The `--no-shrinkwrap` argument, which will ignore an available
 package lock or shrinkwrap file and use the package.json instead.
 
+The `--no-package-lock` argument will prevent npm from creating a
+`package-lock.json` file.
+
 The `--nodedir=/path/to/node/source` argument will allow npm to find the
 node source code so that npm can compile native modules.
 
diff --git a/deps/npm/doc/cli/npm-ls.md b/deps/npm/doc/cli/npm-ls.md
index 65e8366d46..e665a735c3 100644
--- a/deps/npm/doc/cli/npm-ls.md
+++ b/deps/npm/doc/cli/npm-ls.md
@@ -91,6 +91,13 @@ When "dev" or "development", is an alias to `dev`.
 
 When "prod" or "production", is an alias to `production`.
 
+### link
+
+* Type: Boolean
+* Default: false
+
+Display only dependencies which are linked
+
 ## SEE ALSO
 
 * npm-config(1)
diff --git a/deps/npm/doc/cli/npm-run-script.md b/deps/npm/doc/cli/npm-run-script.md
index f1389c21c6..b79d58fb01 100644
--- a/deps/npm/doc/cli/npm-run-script.md
+++ b/deps/npm/doc/cli/npm-run-script.md
@@ -3,7 +3,7 @@ npm-run-script(1) -- Run arbitrary package scripts
 
 ## SYNOPSIS
 
-    npm run-script <command> [-- <args>...]
+    npm run-script <command> [--silent] [-- <args>...]
 
     alias: npm run
 
@@ -50,6 +50,8 @@ not found in the `PATH`.
 If you try to run a script without having a `node_modules` directory and it fails,
 you will be given a warning to run `npm install`, just in case you've forgotten.
 
+You can use the `--silent` flag to prevent showing `npm ERR!` output on error.
+
 ## SEE ALSO
 
 * npm-scripts(7)
diff --git a/deps/npm/doc/cli/npm-uninstall.md b/deps/npm/doc/cli/npm-uninstall.md
index e870b23d5c..38302b20d6 100644
--- a/deps/npm/doc/cli/npm-uninstall.md
+++ b/deps/npm/doc/cli/npm-uninstall.md
@@ -3,7 +3,7 @@ npm-uninstall(1) -- Remove a package
 
 ## SYNOPSIS
 
-    npm uninstall [<@scope>/]<pkg>[@<version>]... [-S|--save|-D|--save-dev|-O|--save-optional]
+    npm uninstall [<@scope>/]<pkg>[@<version>]... [-S|--save|-D|--save-dev|-O|--save-optional|--no-save]
 
     aliases: remove, rm, r, un, unlink
 
@@ -28,6 +28,8 @@ the package version in your main package.json:
 
 * `-O, --save-optional`: Package will be removed from your `optionalDependencies`.
 
+* `--no-save`: Package will not be removed from your `package.json` file.
+
 Further, if you have an `npm-shrinkwrap.json` then it will be updated as
 well.
 
@@ -39,6 +41,7 @@ Examples:
     npm uninstall @myorg/privatepackage --save
     npm uninstall node-tap --save-dev
     npm uninstall dtrace-provider --save-optional
+    npm uninstall lodash --no-save
 
 ## SEE ALSO
 
diff --git a/deps/npm/doc/files/npm-folders.md b/deps/npm/doc/files/npm-folders.md
index 62ecebc27a..74c7883443 100644
--- a/deps/npm/doc/files/npm-folders.md
+++ b/deps/npm/doc/files/npm-folders.md
@@ -20,10 +20,9 @@ This document will tell you what it puts where.
 ### prefix Configuration
 
 The `prefix` config defaults to the location where node is installed.
-On most systems, this is `/usr/local`. On windows, this is the exact
-location of the node.exe binary.  On Unix systems, it's one level up,
-since node is typically installed at `{prefix}/bin/node` rather than
-`{prefix}/node.exe`.
+On most systems, this is `/usr/local`. On Windows, it's `%AppData%\npm`.
+On Unix systems, it's one level up, since node is typically installed at
+`{prefix}/bin/node` rather than `{prefix}/node.exe`.
 
 When the `global` flag is set, npm installs things into this prefix.
 When it is not set, it uses the root of the current package, or the
diff --git a/deps/npm/doc/files/npm-shrinkwrap.json.md b/deps/npm/doc/files/npm-shrinkwrap.json.md
index 8256398e86..541a1f5a6d 100644
--- a/deps/npm/doc/files/npm-shrinkwrap.json.md
+++ b/deps/npm/doc/files/npm-shrinkwrap.json.md
@@ -5,7 +5,7 @@ npm-shrinkwrap.json(5) -- A publishable lockfile
 
 `npm-shrinkwrap.json` is a file created by npm-shrinkwrap(1). It is identical to
 `package-lock.json`, with one major caveat: Unlike `package-lock.json`,
-`npm-shrinwkrap.json` may be included when publishing a package.
+`npm-shrinkwrap.json` may be included when publishing a package.
 
 The recommended use-case for `npm-shrinkwrap.json` is applications deployed
 through the publishing process on the registry: for example, daemons and
@@ -13,7 +13,7 @@ command-line tools intended as global installs or `devDependencies`. It's
 strongly discouraged for library authors to publish this file, since that would
 prevent end users from having control over transitive dependency updates.
 
-Additionally, if both `package-lock.json` and `npm-shrinwkrap.json` are present
+Additionally, if both `package-lock.json` and `npm-shrinkwrap.json` are present
 in a package root, `package-lock.json` will be ignored in favor of this file.
 
 For full details and description of the `npm-shrinkwrap.json` file format, refer
diff --git a/deps/npm/doc/files/package-lock.json.md b/deps/npm/doc/files/package-lock.json.md
index f6dde36492..4c134fc229 100644
--- a/deps/npm/doc/files/package-lock.json.md
+++ b/deps/npm/doc/files/package-lock.json.md
@@ -127,6 +127,6 @@ The dependencies of this dependency, exactly as at the top level.
 ## SEE ALSO
 
 * npm-shrinkwrap(1)
-* package-lock.json(5)
+* npm-shrinkwrap.json(5)
 * package.json(5)
 * npm-install(1)
diff --git a/deps/npm/doc/files/package.json.md b/deps/npm/doc/files/package.json.md
index 1a06ff794b..1b2b04fe2f 100644
--- a/deps/npm/doc/files/package.json.md
+++ b/deps/npm/doc/files/package.json.md
@@ -451,18 +451,28 @@ install time.
 
 ### Git URLs as Dependencies
 
-Git urls can be of the form:
+Git urls are of the form:
 
-    git://github.com/user/project.git#commit-ish
-    git+ssh://user@hostname:project.git#commit-ish
-    git+ssh://user@hostname/project.git#commit-ish
-    git+http://user@hostname/project/blah.git#commit-ish
-    git+https://user@hostname/project/blah.git#commit-ish
+    <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
 
-The `commit-ish` can be any tag, sha, or branch which can be supplied as
-an argument to `git checkout`.  The default is `master`.
+`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
+`git+file`.
 
-## GitHub URLs
+If `#<commit-ish>` is provided, it will be used to clone exactly that
+commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
+be any valid semver range or exact version, and npm will look for any tags
+or refs matching that range in the remote repository, much as it would for a
+registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
+specified, then `master` is used.
+
+Examples:
+
+    git+ssh://git@github.com:npm/npm.git#v1.0.27
+    git+ssh://git@github.com:npm/npm#semver:^5.0
+    git+https://isaacs@github.com/npm/npm.git
+    git://github.com/npm/npm.git#v1.0.27
+
+### GitHub URLs
 
 As of version 1.1.65, you can refer to GitHub urls as just "foo":
 "user/foo-project".  Just as with git URLs, a `commit-ish` suffix can be
@@ -478,7 +488,7 @@ included.  For example:
       }
     }
 
-## Local Paths
+### Local Paths
 
 As of version 2.0.0 you can provide a path to a local directory that contains a
 package. Local paths can be saved using `npm install -S` or
@@ -700,12 +710,11 @@ The host architecture is determined by `process.arch`
 
 ## preferGlobal
 
-If your package is primarily a command-line application that should be
-installed globally, then set this value to `true` to provide a warning
-if it is installed locally.
+**DEPRECATED**
 
-It doesn't actually prevent users from installing it locally, but it
-does help prevent some confusion if it doesn't work as expected.
+This option used to trigger an npm warning, but it will no longer warn. It is
+purely there for informational purposes. It is now recommended that you install
+any binaries as local devDependencies wherever possible.
 
 ## private
 
diff --git a/deps/npm/doc/misc/npm-config.md b/deps/npm/doc/misc/npm-config.md
index 6fee98a90c..dd0993d6bb 100644
--- a/deps/npm/doc/misc/npm-config.md
+++ b/deps/npm/doc/misc/npm-config.md
@@ -9,8 +9,14 @@ npm gets its configuration values from the following sources, sorted by priority
 
 Putting `--foo bar` on the command line sets the `foo` configuration
 parameter to `"bar"`.  A `--` argument tells the cli parser to stop
-reading flags.  A `--flag` parameter that is at the *end* of the
-command will be given the value of `true`.
+reading flags.  Using `--flag` without specifying any value will set
+the value to `true`.
+
+Example: `--flag1 --flag2` will set both configuration parameters
+to `true`, while `--flag1 --flag2 bar` will set `flag1` to `true`,
+and `flag2` to `bar`.  Finally, `--flag1 --flag2 -- bar` will set
+both configuration parameters to `true`, and the `bar` is taken
+as a command argument.
 
 ### Environment Variables
 
@@ -21,7 +27,7 @@ configuration parameter to `bar`.  Any environment configurations that
 are not given a value will be given the value of `true`.  Config
 values are case-insensitive, so `NPM_CONFIG_FOO=bar` will work the
 same. However, please note that inside [npm-scripts](/misc/scripts)
-npm will set it's own environment variables and Node will prefer
+npm will set its own environment variables and Node will prefer
 those lowercase versions over any uppercase ones that you might set.
 For details see [this issue](https://github.com/npm/npm/issues/14528).
 
@@ -31,9 +37,9 @@ The four relevant files are:
 
 * per-project configuration file (`/path/to/my/project/.npmrc`)
 * per-user configuration file (defaults to `$HOME/.npmrc`; configurable via CLI
-  option `--userconfig` or environment variable `$NPM_CONF_USERCONFIG`)
+  option `--userconfig` or environment variable `$NPM_CONFIG_USERCONFIG`)
 * global configuration file (defaults to `$PREFIX/etc/npmrc`; configurable via
-  CLI option `--globalconfig` or environment variable `$NPM_CONF_GLOBALCONFIG`)
+  CLI option `--globalconfig` or environment variable `$NPM_CONFIG_GLOBALCONFIG`)
 * npm's built-in configuration file (`/path/to/npm/npmrc`)
 
 See npmrc(5) for more details.
@@ -883,6 +889,13 @@ in to a private registry for the first time:
 will cause `@organization` to be mapped to the registry for future installation
 of packages specified according to the pattern `@organization/package`.
 
+### script-shell
+
+* Default: `null`
+* Type: path
+
+The shell to use for scripts run with the `npm run` command.
+
 ### scripts-prepend-node-path
 
 * Default: "warn-only"
diff --git a/deps/npm/doc/misc/npm-scripts.md b/deps/npm/doc/misc/npm-scripts.md
index 0e9c3bc6e7..9cdf588397 100644
--- a/deps/npm/doc/misc/npm-scripts.md
+++ b/deps/npm/doc/misc/npm-scripts.md
@@ -70,11 +70,6 @@ allow users to avoid the confusing behavior of existing npm versions and only
 run on `npm publish` (for instance, running the tests one last time to ensure
 they're in good shape).
 
-**IMPORTANT:** As of `npm@5`, `prepublish` will _only_ be run for `npm
-publish`.  This will make its behavior identical to `prepublishOnly`, so
-`npm@6` or later may drop support for the use of `prepublishOnly`, and then
-maybe we can all forget this embarrassing thing ever happened.
-
 See <https://github.com/npm/npm/issues/10074> for a much lengthier
 justification, with further reading, for this change.
 
diff --git a/deps/npm/doc/spec/package-lock.md b/deps/npm/doc/spec/package-lock.md
new file mode 100644
index 0000000000..e7a7141139
--- /dev/null
+++ b/deps/npm/doc/spec/package-lock.md
@@ -0,0 +1,276 @@
+# package-lock and npm-shrinkwrap
+
+`npm` can have one of two different lock files:
+
+* `package-lock.json`, which is ordinarily always present and is never published.
+* `npm-shrinkwrap.json`, which is created with `npm shrinkwrap` and usually published.
+
+You can only have one of them and in the event that you have both,
+`npm-shrinkwrap.json` takes precedence.  The files are exactly the same
+format and in fact all the `npm shrinkwrap` command does is rename your
+`package-lock.json`.
+
+Through the rest of this document we will refer to the package-lock and
+`package-lock.json` but everything also applies to `npm-shrinkwrap.json`.
+
+## File Format
+
+### name
+
+The name of the package this is a package-lock for. This must match what's in `package.json`.
+
+### version
+
+The version of the package this is a package-lock for. This must match what's in `package.json`.
+
+### lockfileVersion *(new)*
+
+An integer version, starting at `1` with the version number of this document
+whose semantics were used when generating this `package-lock.json`.
+
+### preserveSymlinks *(new)*
+
+Indicates that the install was done with the environment variable
+`NODE_PRESERVE_SYMLINKS` enabled. The installer should insist that the value of this
+property match that environment variable.
+
+### dependencies
+
+These are the modules installed in the `node_modules`.  Some of these are
+dependencies some of these are transitive dependencies (that is,
+dependencies of our dependencies).
+
+This is a mapping of package name to dependency object.  Dependency objects have the
+following properties:
+
+#### version *(changed)*
+
+This is a specifier that uniquely identifies this package and should be
+usable in fetching a new copy of it.
+
+* bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
+* registry sources: This is a version number. (eg, `1.2.3`)
+* git sources: This is a git specifier with resolved committish. (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`)
+* http tarball sources: This is the URL of the tarball. (eg, `https://example.com/example-1.3.0.tgz`)
+* local tarball sources: This is the file URL of the tarball. (eg `file:///opt/storage/example-1.3.0.tgz`)
+* local link sources: This is the file URL of the link. (eg `file:libs/our-module`)
+
+#### integrity *(new)*
+
+This is a [Standard Subresource
+Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) for
+this resource.
+
+* For bundled dependencies this is not included, regardless of source.
+* For registry sources, this is the `integrity` that the registry provided, or if one wasn't provided the SHA1 in `shasum`.
+* For git sources this is the specific commit hash we cloned from.
+* For remote tarball sources this is an integrity based on a SHA512 of
+  the file.
+* For local tarball sources: This is an integrity field based on the SHA512 of the file.
+
+#### resolved
+
+* For bundled dependencies this is not included, regardless of source.
+* For registry sources this is path of the tarball relative to the registry
+  URL.  If the tarball URL isn't on the same server as the registry URL then
+  this is a complete URL.
+
+#### link *(new)*
+
+If this module was symlinked in development but had semver in the
+`package.json` then this is the relative path of that link.
+
+Discussion of the semantics of this will go in the symlinks RFC.
+
+Implementation note: To be implemented post npm@5.
+
+#### bundled *(new)*
+
+If true, this is the bundled dependency and will be installed by the parent
+module.  When installing, this module will be extracted from the parent
+module during the extract phase, not installed as a separate dependency.
+
+#### dev
+
+If true then this dependency is either a development dependency ONLY of the
+top level module or a transitive dependency of one.  This is false for
+dependencies that are both a development dependency of the top level and a
+transitive dependency of a non-development dependency of the top level.
+
+#### optional
+
+If true then this dependency is either an optional dependency ONLY of the
+top level module or a transitive dependency of one.  This is false for
+dependencies that are both an optional dependency of the top level and a
+transitive dependency of a non-optional dependency of the top level.
+
+All optional dependencies should be included even if they're uninstallable
+on the current platform.
+
+#### from *(deprecated)*
+
+This is a record of what specifier was used to originally install this
+package.  This should not be included in new `package-lock.json` files.
+
+#### requires
+
+This is a mapping of module name to version.  This is a list of everything
+this module requires, regardless of where it will be installed.  The version
+should match via normal matching rules a dependency either in our
+`dependencies` or in a level higher than us.
+
+#### dependencies
+
+Exactly like `dependencies` at the top level, this is a list of modules to
+install in the `node_modules` of this module.
+
+## Generating
+
+### `npm init`
+
+If neither a `package-lock.json` nor an `npm-shrinkwrap.json` exist then
+`npm init` will create a `package-lock.json`.  This is functionally
+equivalent to running `npm shrinkwrap` after the current init completes and
+renaming the result to `package-lock.json`.
+
+### `npm install --save`
+
+If either an `npm-shrinkwrap.json` or a `package-lock.json` exists then it
+will be updated.
+
+If neither exist then a `package-lock.json` should be generated.
+
+If a `package.json` does not exist, it should be generated.  The generated
+`package.json` should be empty, as in:
+
+```
+{
+   "dependencies": {
+   }
+}
+```
+
+If the user wants to get a default package name/version added they can run `npm init`.
+
+### `npm shrinkwrap`
+
+If a `package-lock.json` exists, rename it to `npm-shrinkwrap.json`.
+Refresh the data from the installer's ideal tree.
+
+The top level `name` and `version` come from the `package.json`.  It is an
+error if either are missing or invalid.
+
+#### dependencies.dev
+
+This is `true` if this dependency is ONLY installed to fulfill either a top
+level development dependency, or one of its transitive dependencies.
+
+Given:
+```
+B (Dev) → C
+```
+
+Then both B and C would be `dev: true`.
+
+Given:
+```
+A → B → C
+B (Dev) -> C
+```
+
+Then all dependencies would be `dev: false`.
+
+#### dependencies.optional
+
+This is `true` if this dependency is ONLY ever either an optional dependency
+or a transitive dependency of optional dependencies.
+
+Given:
+```
+A (Opt) → B → C
+```
+
+Then all three of A, B and C would be flagged as optional.
+
+Given:
+```
+A (Opt) → B → C
+D → C
+```
+
+Then A and B would be flagged as optional, but C would not be.
+
+Given:
+```
+A (Opt) → B → C
+D → A
+```
+
+Then none would be flagged as optional.
+
+## Installing
+
+If the `packageIntegrity` in the `package-lock.json` differs from the one
+computed from the `package.json` then places where the `package.json` is
+incompatible with the `package-lock.json` a new module should be installed.
+That is, while the `package-lock.json` ordinarily defines the state of your
+project, if your `package.json` is edited independently it will take
+precedence.
+
+The `package-lock.json` describes the exact tree that `npm` should create.
+Any deviation between the `package.json` and the shrinkwrap/lock should
+result in a warning be issued.  This includes:
+
+* Modules in `package.json` but missing from the `package-lock.json`
+* Modules in the `package-lock.json` but missing from the `package.json`.
+* Modules in `package.json` whose specifiers don't match the version in `package-lock.json`.
+
+Warn if the `lockfileVersion` in the `package-lock.json` is for a different
+major version than we implement.
+
+Module resolution from package-lock data works as such:
+
+* If install was run with `--resolve-links` and a dependency has a `link`
+  property then a symlink is made using that.  If the version of the
+  destination can not be matched to the package-lock and/or the package.json
+  then a warning will be issued.
+
+* Otherwise, if a `integrity` is available then we try to install it from the cache using it.
+
+If `integrity` is unavailable or we are unable to locate a module from the `integrity` then:
+
+* If `lockfileVersion` is set:
+  * Install using the value of `version` and validate the result against the
+    `integrity`.
+* Otherwise, try these in turn and validate the result against the `integrity`:
+  * `resolved`, then `from`, then `version.
+  * `from` can be either `package@specifier` or just `specifier`.
+
+Regardless of how the module is installed the metadata in the installed
+module should be identical to what it would have been if the module were
+installed w/o a package-lock.
+
+## Implied Changes To Other Commands
+
+### `npm rm --save`
+
+Currently if you ask to remove a package that's both a direct and a
+transitive dependency, we'll remove the package from `node_modules` even if
+this results in a broken tree.  This was chosen at the time because we felt
+that users would expect `npm rm pkgname` to be equivalent of
+`rm -rf node_modules/pkgname`.
+
+As you are no longer going to be allowed to put your `node_modules` in a
+state that's not a valid package-lock, this means this behavior is no longer
+valid.  Instead we should follow normal rules, removing it from the
+dependencies for the top level but only removing the module on disk if
+nothing requires it any more.
+
+## Additional fields / Adding new fields
+
+Installers should ignore any field they aren't aware of.  It's not an error
+to have additional properities in the package-lock or lock file.
+
+Installers that want to add new fields should either have one added via RFC
+in the npm issue tracker and an accompanying documentation PR, or should prefix
+it with the name of their project.