deps: upgrade npm to 7.0.2

Refs: https://github.com/npm/cli/blob/latest/CHANGELOG.md#702-2020-10-16

PR-URL: #35667
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>

deps/npm/AUTHORS

@@ -696,14 +696,29 @@ Naix Geng <1308363651@qq.com>
 Dylan Treisman <dylanzt@gmail.com>
 mum-never-proud <abhuz@hotmail.com>
 Pablo Cúbico <pablocuadrado@gmail.com>
+Peter Fich <peterfich@users.noreply.github.com>
+Maxwell Gerber <mgerber@berkeley.edu>
+Sean Poulter <sean.poulter@gmail.com>
+vanishcode <vanishcode@outlook.com>
 Timo Sand <timo.sand@iki.fi>
+Jean-Charles Sisk <jasisk@gmail.com>
+Martin Packman <martin@zegami.com>
+Danielle Adams <danielle.adams@heroku.com>
 Edward Thomson <ethomson@edwardthomson.com>
 Masafumi Koba <ybiquitous@gmail.com>
+Gianfranco Costamagna <costamagnagianfranco@yahoo.it>
+Antonio <antonio.olmo@devo.com>
+Sandra Tatarevićová <sandra@tatarevicova.cz>
+Antoine du Hamel <duhamelantoine1995@gmail.com>
+Assaf Sapir <assapir@github.com>
 jamesgeorge007 <jamesgeorge998001@gmail.com>
+Lukas Spieß <lumaxis@github.com>
 Mickael Jeanroy <mickael.jeanroy@gmail.com>
 Myles Borins <mylesborins@github.com>
 Nathan LaFreniere <quitlahok@gmail.com>
 Lucio Martinez <lucio.martinez@sixt.com>
 Brian Jenkins <brian@npmjs.com>
 nlf <quitlahok@gmail.com>
 zhaoxuxu <zhaoxuxujc@gmail.com>
+liuye.adam <liuye.adam@bytedance.com>
+Michaël Zasso <targos@protonmail.com>

deps/npm/CHANGELOG.md

@@ -1,3 +1,67 @@
+## 7.0.2 (2020-10-16)
+
+### DOCUMENTATION
+
+* [`9476734b7`](https://github.com/npm/cli/commit/9476734b7d5fa6df80ad17ad277a6bee9a16235c)
+  [#1967](https://github.com/npm/cli/pull/1967)
+  add mention to workspaces prepare lifecycle
+  ([@ruyadorno](https://github.com/ruyadorno))
+
+### BUG FIXES
+
+* [`5cf71c689`](https://github.com/npm/cli/commit/5cf71c689bcfcd423405e59d05b7cc5704cb4c02)
+  [#1971](https://github.com/npm/cli/pull/1971)
+  owner rm at local pkg not work
+  ([@ShangguanQuail](https://github.com/ShangguanQuail))
+
+### DEPENDENCIES
+
+* [`722b7ae63`](https://github.com/npm/cli/commit/722b7ae63da8b386fe188066dc2dae0121d9353b)
+  [#1974](https://github.com/npm/cli/pull/1974)
+  patch node-gyp
+  ([@targos](https://github.com/MylesBorins))
+* [`4ae825c01`](https://github.com/npm/cli/commit/4ae825c01c7ca3031361f9df72594a190c6ed1e4)
+  [#1976](https://github.com/npm/cli/pull/1976)
+  patch node-gyp
+  ([@MylesBorins](https://github.com/MylesBorins))
+* [`181eabf13`](https://github.com/npm/cli/commit/181eabf132c823af086380368de73d2f42e5aac1)
+  `@npmcli/arborist@1.0.3`
+    * fix workspaces `prepare` lifecycle scripts
+    * fix peer deps overchecks resulting in ERESOLVE
+* [`6cc115409`](https://github.com/npm/cli/commit/6cc115409b7eb2df8e11db6232ee3d00e4316a7d)
+  `init-package-json@2.0.1`
+* [`dbf9d6d1f`](https://github.com/npm/cli/commit/dbf9d6d1f060ea43b700409306574396a798127d)
+  `libnpmpublish@3.0.2`
+
+## 7.0.1 (2020-10-15)
+
+### DOCUMENTATION
+
+* [`03fca6a3b`](https://github.com/npm/cli/commit/03fca6a3b227f71562863bec7a1de1732bd719f1)
+  Adds docs on workspaces, explaining its basic concept and how to use it.
+  ([@ruyadorno](https://github.com/ruyadorno))
+
+### BUG FIXES
+
+* [`2ccb63659`](https://github.com/npm/cli/commit/2ccb63659f9a757201658d5d019099b492d04a5b)
+  [#1951](https://github.com/npm/cli/issues/1951)
+  [#1956](https://github.com/npm/cli/pull/1956)
+  Handle errors from audit endpoint appropriately
+  ([@isaacs](https://github.com/isaacs))
+
+### DEPENDENCIES
+
+* [`120e62736`](https://github.com/npm/cli/commit/120e6273604f15a2ce55668dfb2c23d06bf1e06c)
+  `node-gyp@7.1.1`
+* [`6560b8d95`](https://github.com/npm/cli/commit/6560b8d952a613cefbd900186aa38df53bc201d1)
+  `@npmcli/arborist@1.0.2`
+    * do not drop scope information when fetching scoped package tarballs
+    * fix cycles/ordering resolution when peer deps require nesting
+* [`282a1e008`](https://github.com/npm/cli/commit/282a1e00820b9abfb3465d044b30b2cade107909)
+  `npm-user-validate@1.0.1`
+* [`b259edcb4`](https://github.com/npm/cli/commit/b259edcb4bac37e6f26d56af5f6666afbda8c126)
+  `hosted-git-info@3.0.7`
+
 ## v7.0.0 (2020-10-12)
 
 ### BUG FIXES

deps/npm/CONTRIBUTING.md

@@ -123,7 +123,7 @@ We often want to know if the bug we've fixed for the feature we've added has any
 1. Make a pull-request against this repository
 2. Add the following comment to the pull-request: "`test this please ✅`"
 
-This will trigger the [benmark suite](https://github.com/npm/benchmarks) to run against your pull-request, and when it's finished running it will post a comment on your pull-request just like bellow. You'll be able to see the results from the suite inline in your pull-request.
+This will trigger the [benchmark suite](https://github.com/npm/benchmarks) to run against your pull-request, and when it's finished running it will post a comment on your pull-request just like below. You'll be able to see the results from the suite inline in your pull-request.
 
 > You'll notice that the bot-user will also add a 🚀 reaction to your comment to
 let you know that it's sent the request to start the benchmark suite.
@@ -186,6 +186,6 @@ You'll need a few things installed in order to update and test the CLI project d
 
 > Package vendoring is commonly referred to as the case where dependent packages are stored in the same place as your project. That usually means you dependencies are checked into your source management system, such as Git.
 
-The CLI project vendors it's dependencies in the `node_modules/` folder. Meaning all the dependencies that the CLI project uses are contained withing the project itself. This is represented by the `bundledDependencies` section in the root level `package.json` file. The main reason for this is because the `npm` CLI project is distributed with the NodeJS runtime and needs to work out of the box, which means all dependencies need to be available after the runtime is installed.
+The CLI project vendors its dependencies in the `node_modules/` folder. Meaning all the dependencies that the CLI project uses are contained within the project itself. This is represented by the `bundledDependencies` section in the root level `package.json` file. The main reason for this is because the `npm` CLI project is distributed with the NodeJS runtime and needs to work out of the box, which means all dependencies need to be available after the runtime is installed.
 
 There are a couple scripts created to help manage this process in the `scripts/` folder.

deps/npm/docs/content/cli-commands/npm-install.md

@@ -34,7 +34,6 @@ package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, the
 installation of dependencies will be driven by that, respecting the following
 order of precedence:
 
-* `node_modules/.package-lock.json`
 * `npm-shrinkwrap.json`
 * `package-lock.json`
 * `yarn.lock`
@@ -495,3 +494,4 @@ specific folder structures that npm creates.
 * [npm uninstall](/cli-commands/uninstall)
 * [npm shrinkwrap](/cli-commands/shrinkwrap)
 * [package.json](/configuring-npm/package-json)
+* [workspaces](/using-npm/workspaces)

deps/npm/docs/content/configuring-npm/package-json.md

@@ -886,6 +886,31 @@ probably matter for the purposes of publishing.
 See [`config`](/using-npm/config) to see the list of config options that can be
 overridden.
 
+### workspaces
+
+The optional `workspaces` field is an array of file patterns that describes
+locations within the local file system that the install client should look up
+to find each [workspace](/using-npm/workspaces) that needs to be symlinked to
+the top level `node_modules` folder.
+
+It can describe either the direct paths of the folders to be used as
+workspaces or it can define globs that will resolve to these same folders.
+
+In the following example, all folders located inside the folder `./packages`
+will be treated as workspaces as long as they have valid `package.json` files
+inside them:
+
+```json
+{
+  "name": "workspace-example",
+  "workspaces": [
+    "./packages/*"
+  ]
+}
+```
+
+See [`workspaces`](/using-npm/workspaces) for more examples.
+
 ### DEFAULT VALUES
 
 npm will default some values based on package contents.
@@ -910,6 +935,7 @@ npm will default some values based on package contents.
 ### SEE ALSO
 
 * [semver](/using-npm/semver)
+* [workspaces](/using-npm/workspaces)
 * [npm init](/cli-commands/init)
 * [npm version](/cli-commands/version)
 * [npm config](/cli-commands/config)

deps/npm/docs/content/using-npm/scripts.md

@@ -100,7 +100,7 @@ The advantage of doing these things at `prepublish` time is that they can be don
 Also triggers
 
 * `prepublish` (when on local)
-* `prepare` (when on local)
+* `prepare` (when on local or workspaces)
 
 #### [`npm start`](/cli-commands/start)
 

deps/npm/docs/content/using-npm/workspaces.md

@@ -0,0 +1,97 @@
+---
+section: using-npm
+title: workspaces
+description: Working with workspaces
+---
+# scope(7)
+
+## Workspaces
+
+### Description
+
+**Workspaces** is a generic term that refers to the set of features in the
+npm cli that provides support to managing multiple packages from your local
+files system from within a singular top-level, root package.
+
+This set of features makes up for a much more streamlined workflow handling
+linked packages from the local file system. Automating the linking process
+as part of `npm install` and avoiding manually having to use `npm link` in
+order to add references to packages that should be symlinked into the current
+`node_modules` folder.
+
+We also refer to these packages being auto-symlinked during `npm install` as a
+single **workspace**, meaning it's a nested package within the current local
+file system that is explicitly defined in the [`package.json`](/using-npm/package-json)
+`workspaces` configuration.
+
+### Installing workspaces
+
+Workspaces are usually defined via the `workspaces` property of the
+[`package.json`](/using-npm/package-json) file, e.g:
+
+```json
+{
+  "name": "my-workspaces-powered-project",
+  "workspaces": [
+    "workspace-a"
+  ]
+}
+```
+
+Given the above `package.json` example living at a current working
+directory `.` that contains a folder named `workspace-a` that disposes
+of a `package.json` inside it, defining a nodejs package, e.g:
+
+```
+.
++-- package.json
+`-- workspace-a
+   `-- package.json
+```
+
+The expected result once running `npm install` in this current working
+directory `.` is that the folder `workspace-a` will get symlinked to the
+`node_modules` folder of the current working dir.
+
+Below is a post `npm install` example, given that same previous example
+structure of files and folders:
+
+```
+.
++-- node_modules
+|  `-- workspace-a -> ../workspace-a
++-- package-lock.json
++-- package.json
+`-- workspace-a
+   `-- package.json
+```
+
+### Using workspaces
+
+Given the [specifities of how Node.js handles module resolution](https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together) it's possible to consume any defined workspace
+by it's declared `package.json` `name`. Continuing from the example defined
+above, let's also create a Node.js script that will require the `workspace-a`
+example module, e.g:
+
+```
+// ./workspace-a/index.js
+module.exports = 'a'
+
+// ./lib/index.js
+const moduleA = require('workspace-a')
+console.log(moduleA) // -> a
+```
+
+When running it with:
+
+`node lib/index.js`
+
+This demonstrates how the nature of `node_modules` resolution allows for
+**workspaces** to enable a portable workflow for requiring each **workspace**
+in such a way that is also easy to [publish](/cli-commands/publish) these
+nested workspaces to be consumed elsewhere.
+
+### See also
+
+* [npm install](/cli-commands/install)
+* [npm publish](/cli-commands/publish)