CLI documentation update from CI

Author: npm-cli-bot

cli-cache.json

@@ -2,5 +2,5 @@
   "v8": "aa8fff11cdab94fff1a2160ee5241f5f4632e96b",
   "v9": "64763a341e7aa5b456e696f956759bf9b3440dc1",
   "v10": "e510f14bf6a20d67e7b37c3f25ff271d9f7a0da5",
-  "v11": "8f6eb6b29904b5a807c5c4c01c1246afc70a77f1"
+  "v11": "5d7a7a8695135812d55f42ab03513c705d7fd785"
 }

content/cli/v11/commands/npm-ls.mdx

@@ -52,7 +52,7 @@ Note: to get a "bottoms up" view of why a given package is included in the tree
 Positional arguments are `name@version-range` identifiers, which will limit the results to only the paths to the packages named. Note that nested packages will _also_ show the paths to the specified packages. For example, running `npm ls promzard` in npm's source tree will show:
 
 ```bash
-npm@11.4.0 /path/to/npm
+npm@11.4.1 /path/to/npm
 └─┬ init-package-json@0.0.4
   └── promzard@0.1.5
 ```

content/cli/v11/commands/npm.mdx

@@ -31,7 +31,7 @@ Note: This command is unaware of workspaces.
 
 ### Version
 
-11.4.0
+11.4.1
 
 ### Description
 

content/cli/v11/using-npm/changelog.mdx

@@ -15,6 +15,25 @@ redirect_from:
   - /using-npm/changelog
 ---
 
+## [11.4.1](https://github.com/npm/cli/compare/v11.4.0...v11.4.1) (2025-05-21)
+
+### Documentation
+
+- [`3ed764a`](https://github.com/npm/cli/commit/3ed764aa08f2087fa1d1bd7391a646ba47565294) [#8308](https://github.com/npm/cli/pull/8308) Clarify script working directory behavior (fixes #8305) (#8308) (@tarekwfa0110, @owlstronaut)
+
+### Chores
+
+- [`2f30251`](https://github.com/npm/cli/commit/2f302516401928239593dd2eebc171729df60537) [#8314](https://github.com/npm/cli/pull/8314) remove references to skimdb.npmjs.com (#8314) (@shmam)
+- [`9cb9d50`](https://github.com/npm/cli/commit/9cb9d5030b1fdb83e3ffa45b7c8d2de80a657768) [#8298](https://github.com/npm/cli/pull/8298) add contributor to changelog entry (#8298) (@wraithgar)
+
+### Dependencies
+
+- [workspace](https://github.com/npm/cli/releases/tag/arborist-v9.1.1): `@npmcli/arborist@9.1.1`
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmdiff-v8.0.4): `libnpmdiff@8.0.4`
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmexec-v10.1.3): `libnpmexec@10.1.3`
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmfund-v7.0.4): `libnpmfund@7.0.4`
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmpack-v9.0.4): `libnpmpack@9.0.4`
+
 ## [11.4.0](https://github.com/npm/cli/compare/v11.3.0...v11.4.0) (2025-05-15)
 
 ### Features

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

@@ -27,8 +27,6 @@ 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/v11/using-npm/scope). If no scope is specified, the default registry is used, which is supplied by the [`registry` config](/cli/v11/using-npm/config#registry) parameter. See [`npm config`](/cli/v11/commands/npm-config), [`npmrc`](/cli/v11/configuring-npm/npmrc), and [`config`](/cli/v11/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/v11/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.

content/cli/v11/using-npm/scripts.mdx

@@ -218,6 +218,21 @@ Reasons for a package removal include:
 
 Due to the lack of necessary context, `uninstall` lifecycle scripts are not implemented and will not function.
 
+### Working Directory for Scripts
+
+Scripts are always run from the root of the package folder, regardless of what the current working directory is when `npm` is invoked. This means your scripts can reliably assume they are running in the package root.
+
+If you want your script to behave differently based on the directory you were in when you ran `npm`, you can use the `INIT_CWD` environment variable, which holds the full path you were in when you ran `npm run`.
+
+#### Historical Behavior in Older npm Versions
+
+For npm v6 and earlier, scripts were generally run from the root of the package, but there were rare cases and bugs in older versions where this was not guaranteed. If your package must support very old npm versions, you may wish to add a safeguard in your scripts (for example, by checking process.cwd()).
+
+For more details, see:
+
+- [npm v7 release notes](https://github.com/npm/cli/releases/tag/v7.0.0)
+- [Discussion about script working directory reliability in npm v6 and earlier](https://github.com/npm/npm/issues/12356)
+
 ### User
 
 When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner.
@@ -302,7 +317,6 @@ Note that these script files don't have to be Node.js or even JavaScript program
 - Inspect the env to determine where to put things. For instance, if the `npm_config_binroot` environment variable is set to `/home/user/bin`, then don't try to install executables into `/usr/local/bin`. The user probably set it up that way for a reason.
 - Don't prefix your script commands with "sudo". If root permissions are required for some reason, then it'll fail with that error, and the user will sudo the npm command in question.
 - Don't use `install`. Use a `.gyp` file for compilation, and `prepare` for anything else. You should almost never have to explicitly set a preinstall or install script. If you are doing this, please consider if there is another option. The only valid use of `install` or `preinstall` scripts is for compilation which must be done on the target architecture.
-- Scripts are run from the root of the package folder, regardless of what the current working directory is when `npm` is invoked. If you want your script to use different behavior based on what subdirectory you're in, you can use the `INIT_CWD` environment variable, which holds the full path you were in when you ran `npm run`.
 
 ### See Also
 

content/nav.yml

@@ -1594,7 +1594,7 @@
             - title: Changelog
               url: /cli/v10/using-npm/changelog
               description: Changelog notes for each version
-    - title: Version 11.4.0
+    - title: Version 11.4.1
       shortName: v11
       url: /cli/v11
       default: true