CLI documentation update from CI
npm CLI robot committed
Apr 23, 2025 at 15:59 UTC
433f1b89317c55b7a5ae7460b8fdb3bbf939b8d3
3 files changed
+4
-2
cli-cache.json
+1
-1
@@ -1,6 +1,6 @@
1
{
2
"v8": "aa8fff11cdab94fff1a2160ee5241f5f4632e96b",
3
"v9": "64763a341e7aa5b456e696f956759bf9b3440dc1",
4
- "v10": "a3041941586b6fb8ed7403fe3c24d81138a96005",
4
+ "v10": "e510f14bf6a20d67e7b37c3f25ff271d9f7a0da5",
5
"v11": "4b08e2ed252a18f85a360b76c7273a7aa7a994ca"
6
}
\ No newline at end of file
content/cli/v10/configuring-npm/package-json.mdx
+1
-1
@@ -903,7 +903,7 @@ The `devEngines` field aids engineers working on a codebase to all be using the
903
904
You can specify a `devEngines` property in your `package.json` which will run before `install`, `ci`, and `run` commands.
905
906
-> 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.
906
+> 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.
907
908
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.
909
content/cli/v10/using-npm/registry.mdx
+2
@@ -21,6 +21,8 @@ You can configure npm to use any compatible registry you like, and even run your
21
22
npm's package registry implementation supports several write APIs as well, to allow for publishing packages and managing user account information.
23
24
+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).
25
+
26
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)
27
28
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.