deps: upgrade npm to 5.8.0

PR-URL: nodejs#19560
Fixes: nodejs#19271
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>

deps/npm/.github/issue_template.md

@@ -3,6 +3,7 @@
   - [ ] npm is crashing.
   - [ ] npm is producing an incorrect install.
   - [ ] npm is doing something I don't understand.
+  - [ ] npm is producing incorrect or undesirable behavior.
   - [ ] Other (_see below for feature requests_):
 
 #### What's going wrong?

deps/npm/AUTHORS

@@ -536,3 +536,28 @@ Jacob Wejendorp <jacob@wejendorp.dk>
 Alejandro López <a.lopez.sanchez@outlook.es>
 Victor Belozyorov <hi@vbelozyorov.com>
 Bradley Farias <bfarias@godaddy.com>
+Kyle E. Mitchell <kyle@kemitchell.com>
+Tuan Anh Tran <me@tuananh.org>
+Nathan Woltman <nwoltman@outlook.com>
+Kyra <kyranet@users.noreply.github.com>
+Leаh Neukirchen <chneukirchen@gmail.com>
+Kyle Spier-Swenson <kyleshome@gmail.com>
+Joe Bowbeer <joe.bowbeer@gmail.com>
+Nalin Bhardwaj <6984346+nalinbhardwaj@users.noreply.github.com>
+Nicolas Garnier <ngarnier@users.noreply.github.com>
+Vladislav Rassokhin <vladrassokhin@gmail.com>
+Josh Goldberg <joshuakgoldberg@outlook.com>
+laggingreflex <laggingreflex@gmail.com>
+Kristofer Selbekk <selbekk@users.noreply.github.com>
+sreenivas alapati <sreenivas9alapati@gmail.com>
+Ben Creasy <ben@bencreasy.com>
+Allan Kimmer Jensen <allankimmerjensen@gmail.com>
+rinfan <rinfan@users.noreply.github.com>
+Matt Hoyle <code@deployable.co>
+Mason Pawsey <mpawsey@csub.edu>
+Johannes Bader <olydis@users.noreply.github.com>
+Michael Zabka <zabka.michael@gmail.com>
+Bruce MacNaughton <bmacnaughton@gmail.com>
+Christopher Patty <christopher.patty@aggiemail.usu.edu>
+Max Stoiber <contact@mxstbr.com>
+Enrico Weigelt <enrico.weigelt@gr13.net>

deps/npm/Makefile

@@ -65,7 +65,7 @@ dev: install
 link: uninstall
 	node bin/npm-cli.js link -f
 
-clean: markedclean marked-manclean doc-clean uninstall
+clean: markedclean marked-manclean doc-clean
 	rm -rf npmrc
 	node bin/npm-cli.js cache clean
 

deps/npm/bin/npx

@@ -12,18 +12,19 @@ if ! [ -x "$NODE_EXE" ]; then
   NODE_EXE=node
 fi
 
+NPM_CLI_JS="$basedir/node_modules/npm/bin/npm-cli.js"
 NPX_CLI_JS="$basedir/node_modules/npm/bin/npx-cli.js"
 
 case `uname` in
   *MINGW*)
-    NPM_PREFIX=`"$NODE_EXE" "$NPX_CLI_JS" prefix -g`
+    NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
     NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
     if [ -f "$NPM_PREFIX_NPX_CLI_JS" ]; then
       NPX_CLI_JS="$NPM_PREFIX_NPX_CLI_JS"
     fi
     ;;
   *CYGWIN*)
-    NPM_PREFIX=`"$NODE_EXE" "$NPX_CLI_JS" prefix -g`
+    NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
     NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
     if [ -f "$NPM_PREFIX_NPX_CLI_JS" ]; then
       NPX_CLI_JS="$NPM_PREFIX_NPX_CLI_JS"

deps/npm/bin/npx.cmd

@@ -8,8 +8,9 @@ IF NOT EXIST "%NODE_EXE%" (
   SET "NODE_EXE=node"
 )
 
+SET "NPM_CLI_JS=%~dp0\node_modules\npm\bin\npm-cli.js"
 SET "NPX_CLI_JS=%~dp0\node_modules\npm\bin\npx-cli.js"
-FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPX_CLI_JS%" prefix -g') DO (
+FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_CLI_JS%" prefix -g') DO (
   SET "NPM_PREFIX_NPX_CLI_JS=%%F\node_modules\npm\bin\npx-cli.js"
 )
 IF EXIST "%NPM_PREFIX_NPX_CLI_JS%" (

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

@@ -0,0 +1,58 @@
+npm-ci(1) -- Install a project with a clean slate
+===================================
+
+## SYNOPSIS
+
+    npm ci
+
+## EXAMPLE
+
+Make sure you have a package-lock and an up-to-date install:
+
+```
+$ cd ./my/npm/project
+$ npm install
+added 154 packages in 10s
+$ ls | grep package-lock
+```
+
+Run `npm ci` in that project
+
+```
+$ npm ci
+added 154 packages in 5s
+```
+
+Configure Travis to build using `npm ci` instead of `npm install`:
+
+```
+# .travis.yml
+install:
+- npm ci
+# keep the npm cache around to speed up installs
+cache:
+  directories:
+  - "$HOME/.npm"
+```
+
+## DESCRIPTION
+
+This command is similar to `npm-install(1)`, except it's meant to be used in
+automated environments such as test platforms, continuous integration, and
+deployment. It can be significantly faster than a regular npm install by
+skipping certain user-oriented features. It is also more strict than a regular
+install, which can help catch errors or inconsistencies caused by the
+incrementally-installed local environments of most npm users.
+
+In short, the main differences between using `npm install` and `npm ci` are:
+
+* The project **must** have an existing `package-lock.json` or `npm-shrinkwrap.json`.
+* If dependencies in the package lock do not match those in `package.json`, `npm ci` will exit with an error, instead of updating the package lock.
+* `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
+* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
+* It will never write to `package.json` or any of the package-locks: installs are essentially frozen.
+
+## SEE ALSO
+
+* npm-install(1)
+* npm-package-locks(5)

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

@@ -55,6 +55,9 @@ after packing it up into a tarball (b).
     is set to `production`), npm will not install modules listed in
     `devDependencies`.
 
+    > NOTE: The `--production` flag has no particular meaning when adding a
+    dependency to a project.
+
 * `npm install <folder>`:
 
     Install the package in the directory as a symlink in the current project.
@@ -347,7 +350,8 @@ 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.
+`package-lock.json` file.  When running with package-lock's disabled npm
+will not automatically prune your node modules when installing.
 
 The `--nodedir=/path/to/node/source` argument will allow npm to find the
 node source code so that npm can compile native modules.

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

@@ -76,7 +76,7 @@ Max display depth of the dependency tree.
 
 Display only the dependency tree for packages in `dependencies`.
 
-### dev
+### dev / development
 
 * Type: Boolean
 * Default: false

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

@@ -3,7 +3,7 @@ npm-prune(1) -- Remove extraneous packages
 
 ## SYNOPSIS
 
-    npm prune [[<@scope>/]<pkg>...] [--production]
+    npm prune [[<@scope>/]<pkg>...] [--production] [--dry-run] [--json]
 
 ## DESCRIPTION
 
@@ -16,9 +16,21 @@ package's dependencies list.
 
 If the `--production` flag is specified or the `NODE_ENV` environment
 variable is set to `production`, this command will remove the packages
-specified in your `devDependencies`. Setting `--production=false` will
+specified in your `devDependencies`. Setting `--no-production` will
 negate `NODE_ENV` being set to `production`.
 
+If the `--dry-run` flag is used then no changes will actually be made.
+
+If the `--json` flag is used then the changes `npm prune` made (or would
+have made with `--dry-run`) are printed as a JSON object.
+
+In normal operation with package-locks enabled, extraneous modules are
+pruned automatically when modules are installed and you'll only need
+this command with the `--production` flag.
+
+If you've disabled package-locks then extraneous modules will not be removed
+and it's up to you to run `npm prune` from time-to-time to remove them.
+
 ## SEE ALSO
 
 * npm-uninstall(1)

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

@@ -34,6 +34,9 @@ when operating on them, separated by a colon (`:`). That is, if you have a
   under that organization. If performed on a team, it will instead return a list
   of all users belonging to that particular team.
 
+* edit:
+  Edit a current team.
+
 ## DETAILS
 
 `npm team` always operates directly on the current registry, configurable from

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

@@ -26,6 +26,10 @@ As of `npm@2.6.1`, the `npm update` will only inspect top-level packages.
 Prior versions of `npm` would also recursively inspect all dependencies.
 To get the old behavior, use `npm --depth 9999 update`.
 
+As of `npm@5.0.0`, the `npm update` will change `package.json` to save the
+new version as the minimum required dependency. To get the old behavior,
+use `npm update --no-save`.
+
 ## EXAMPLES
 
 IMPORTANT VERSION NOTE: these examples assume `npm@2.6.1` or later.  For
@@ -104,30 +108,6 @@ If the dependence were on `^0.4.0`:
 Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting
 version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`)
 
-### Recording Updates with `--save`
-
-When you want to update a package and save the new version as
-the minimum required dependency in `package.json`, you can use
-`npm update -S` or `npm update --save`.  For example if
-`package.json` contains:
-
-```
-"dependencies": {
-  "dep1": "^1.1.1"
-}
-```
-
-Then `npm update --save` will install `dep1@1.2.2` (i.e., `latest`),
-and `package.json` will be modified:
-
-```
-"dependencies": {
-  "dep1": "^1.2.2"
-}
-```
-
-Note that `npm` will only write an updated version to `package.json`
-if it installs a new package.
 
 ### Updating Globally-Installed Packages
 

deps/npm/doc/cli/npm.md

@@ -93,7 +93,7 @@ npm is extremely configurable.  It reads its configuration options from
 * Command line switches:  
   Set a config with `--key val`.  All keys take a value, even if they
   are booleans (the config parser doesn't know what the options are at
-  the time of parsing.)  If no value is provided, then the option is set
+  the time of parsing).  If no value is provided, then the option is set
   to boolean `true`.
 * Environment Variables:  
   Set any config by prefixing the name in an environment variable with

deps/npm/doc/files/npm-folders.md

@@ -68,7 +68,7 @@ Man pages are not installed on Windows systems.
 ### Cache
 
 See `npm-cache(1)`.  Cache files are stored in `~/.npm` on Posix, or
-`~/npm-cache` on Windows.
+`%AppData%/npm-cache` on Windows.
 
 This is controlled by the `cache` configuration param.
 

deps/npm/doc/files/npm-package-locks.md

@@ -136,6 +136,25 @@ on. Additionally, the diffs from these changes are human-readable and will
 inform you of any changes npm has made to your `node_modules`, so you can notice
 if any transitive dependencies were updated, hoisted, etc.
 
+### Resolving lockfile conflicts
+
+Occasionally, two separate npm install will create package locks that cause
+merge conflicts in source control systems. As of `npm@5.7.0`, these conflicts
+can be resolved by manually fixing any `package.json` conflicts, and then
+running `npm install [--package-lock-only]` again. npm will automatically
+resolve any conflicts for you and write a merged package lock that includes all
+the dependencies from both branches in a reasonable tree. If
+`--package-lock-only` is provided, it will do this without also modifying your
+local `node_modules/`.
+
+To make this process seamless on git, consider installing
+[`npm-merge-driver`](https://npm.im/npm-merge-driver), which will teach git how
+to do this itself without any user interaction. In short: `$ npx
+npm-merge-driver install -g` will let you do this, and even works with
+pre-`npm@5.7.0` versions of npm 5, albeit a bit more noisily. Note that if
+`package.json` itself conflicts, you will have to resolve that by hand and run
+`npm install` manually, even with the merge driver.
+
 ## SEE ALSO
 
 * https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527

deps/npm/doc/files/package.json.md

@@ -11,11 +11,11 @@ settings described in `npm-config(7)`.
 
 ## name
 
-The *most* important things in your package.json are the name and version fields.
-Those are actually required, and your package won't install without
-them.  The name and version together form an identifier that is assumed
-to be completely unique.  Changes to the package should come along with
-changes to the version.
+If you plan to publish your package, the *most* important things in your
+package.json are the name and version fields as they will be required. The name
+and version together form an identifier that is assumed to be completely unique.
+Changes to the package should come along with changes to the version. If you don't
+plan to publish your package, the name and version fields are optional.
 
 The name is what your thing is called.
 
@@ -44,11 +44,11 @@ A name can be optionally prefixed by a scope, e.g. `@myorg/mypackage`. See
 
 ## version
 
-The *most* important things in your package.json are the name and version fields.
-Those are actually required, and your package won't install without
-them.  The name and version together form an identifier that is assumed
-to be completely unique.  Changes to the package should come along with
-changes to the version.
+If you plan to publish your package, the *most* important things in your
+package.json are the name and version fields as they will be required. The name
+and version together form an identifier that is assumed to be completely unique.
+Changes to the package should come along with changes to the version. If you don't
+plan to publish your package, the name and version fields are optional.
 
 Version must be parseable by
 [node-semver](https://github.com/isaacs/node-semver), which is bundled
@@ -70,6 +70,10 @@ discover your package as it's listed in `npm search`.
 
 The url to the project homepage.
 
+Example:
+
+    "homepage": "https://github.com/owner/project#readme"
+
 ## bugs
 
 The url to your project's issue tracker and / or the email address to which
@@ -168,13 +172,15 @@ npm also sets a top-level "maintainers" field with your npm user info.
 
 ## files
 
-The optional "files" field is an array of file patterns that describes
+The optional `files` field is an array of file patterns that describes
 the entries to be included when your package is installed as a
-dependency. If the files array is omitted, everything except
-automatically-excluded files will be included in your publish. If you
-name a folder in the array, then it will also include the files inside
-that folder (unless they would be ignored by another rule in this
-section.).
+dependency. File patterns follow a similar syntax to `.gitignore`, but
+reversed: including a file, directory, or glob pattern (`*`, `**/*`, and such)
+will make it so that file is included in the tarball when it's packed. Omitting
+the field will make it default to `["*"]`, which means it will include all files.
+
+Some special files and directories are also included or excluded regardless of
+whether they exist in the `files` array (see below).
 
 You can also provide a `.npmignore` file in the root of your package or
 in subdirectories, which will keep files from being included. At the
@@ -226,6 +232,12 @@ This should be a module ID relative to the root of your package folder.
 For most modules, it makes the most sense to have a main script and often not
 much else.
 
+## browser
+
+If your module is meant to be used client-side the browser field should be
+used instead of the main field. This is helpful to hint users that it might
+rely on primitives that aren't available in Node.js modules. (e.g. `window`)
+
 ## bin
 
 A lot of packages have one or more executable files that they'd like to