CLI documentation update from CI

Author: npm-cli-bot

cli-cache.json

@@ -1,6 +1,6 @@
 {
   "v8": "aa8fff11cdab94fff1a2160ee5241f5f4632e96b",
   "v9": "64763a341e7aa5b456e696f956759bf9b3440dc1",
-  "v10": "a3041941586b6fb8ed7403fe3c24d81138a96005",
+  "v10": "e510f14bf6a20d67e7b37c3f25ff271d9f7a0da5",
   "v11": "4b08e2ed252a18f85a360b76c7273a7aa7a994ca"
 }

content/cli/v10/configuring-npm/package-json.mdx

@@ -903,7 +903,7 @@ The `devEngines` field aids engineers working on a codebase to all be using the
 
 You can specify a `devEngines` property in your `package.json` which will run before `install`, `ci`, and `run` commands.
 
-> Note: `devEngines` and `engines` differ in object shape and functionality. `devEngines` is used to declare the intended runtime (node, etc) and/or package manager (npm, etc) to be used by developers working directly in the source code of a project, whereas `engines` is intended for a package to declare the node and/or npm versions it is compatible with.
+> Note: `engines` and `devEngines` differ in object shape. They also function very differently. `engines` is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas `devEngines` is used to alert people interacting with the source code of a project.
 
 The supported keys under the `devEngines` property are `cpu`, `os`, `libc`, `runtime`, and `packageManager`. Each property can be an object or an array of objects. Objects must contain `name`, and optionally can specify `version`, and `onFail`. `onFail` can be `warn`, `error`, or `ignore`, and if left undefined is of the same value as `error`. `npm` will assume that you're running with `node`. Here's an example of a project that will fail if the environment is not `node` and `npm`. If you set `runtime.name` or `packageManager.name` to any other string, it will fail within the npm CLI.
 

content/cli/v10/using-npm/registry.mdx

@@ -21,6 +21,8 @@ You can configure npm to use any compatible registry you like, and even run your
 
 npm's package registry implementation supports several write APIs as well, to allow for publishing packages and managing user account information.
 
+The npm public registry is powered by a CouchDB database, of which there is a public mirror at [https://skimdb.npmjs.com/registry](https://skimdb.npmjs.com/registry).
+
 The registry URL used is determined by the scope of the package (see [`scope`](/cli/v10/using-npm/scope). If no scope is specified, the default registry is used, which is supplied by the [`registry` config](/cli/v10/using-npm/config#registry) parameter. See [`npm config`](/cli/v10/commands/npm-config), [`npmrc`](/cli/v10/configuring-npm/npmrc), and [`config`](/cli/v10/using-npm/config) for more on managing npm's configuration. Authentication configuration such as auth tokens and certificates are configured specifically scoped to an individual registry. See [Auth Related Configuration](/cli/v10/configuring-npm/npmrc#auth-related-configuration)
 
 When the default registry is used in a package-lock or shrinkwrap it has the special meaning of "the currently configured registry". If you create a lock file while using the default registry you can switch to another registry and npm will install packages from the new registry, but if you create a lock file while using a custom registry packages will be installed from that registry even after you change to another registry.