@cryptotaxi247 / documentation / commits / e5dc9fe

CLI documentation update from CI

npm CLI robot committed Dec 9, 2025 at 19:44 UTC e5dc9fe55ba82c8a7faf667d0cf01d5b049b20ec

14 files changed +230 -42

cli-cache.json

+1 -1

@@ -2,5 +2,5 @@

2 "v8": "aa8fff11cdab94fff1a2160ee5241f5f4632e96b",

3 "v9": "64763a341e7aa5b456e696f956759bf9b3440dc1",

4 "v10": "6755ca2d5301b079f9e2581fc72ba2a612171364",

5 - "v11": "54929cef8e26a4698234e5d2499a43b746569b12"

5 + "v11": "4ebb831d93f13cc0b980754bf36abb2982b131f7"

6 }

\ No newline at end of file

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

+13

@@ -121,6 +121,8 @@ Even if you never publish your package, you can still get a lot of benefits of u

121

122 In most cases, this will install the version of the modules tagged as `latest` on the npm registry.

123

124 + **Note:** When installing by name without specifying a version or tag, npm prioritizes versions that match the current Node.js version based on the package's `engines` field. If the `latest` tag points to a version incompatible with your current Node.js version, npm will install the newest compatible version instead. To install a specific version regardless of `engines` compatibility, explicitly specify the version or tag: `npm install <name>@latest`.

125 +

126 Example:

127

128 ```bash

@@ -209,6 +211,15 @@ Even if you never publish your package, you can still get a lot of benefits of u

211 npm install @myorg/privatepackage@"16 - 17"

212 ```

213

214 + **Prerelease versions:** By default, version ranges only match stable versions. To include prerelease versions, they must be explicitly specified in the range. Prerelease versions are tied to a specific version triple (major.minor.patch). For example, `^1.2.3-beta.1` will only match prereleases for `1.2.x`, not `1.3.x`. To match all prereleases for a major version, use a range like `^1.0.0-0`, which will include all `1.x.x` prereleases.

215 +

216 + Example:

217 +

218 + ```bash

219 + npm install package@^1.2.3-beta.1 # Matches 1.2.3-beta.1, 1.2.3-beta.2, 1.2.4-beta.1, etc.

220 + npm install package@^1.0.0-0 # Matches all 1.x.x prereleases and stable versions

221 + ```

222 +

223 - `npm install <git remote url>`:

224

225 Installs the package from the hosted git provider, cloning it with `git`. For a full git remote url, only that URL will be attempted.

@@ -312,6 +323,8 @@ npm install sax@">=0.1.0 <0.2.0" bench supervisor

323

324 The `--tag` argument will apply to all of the specified install targets. If a tag with the given name exists, the tagged version is preferred over newer versions.

325

326 +**Note:** The `--tag` option only affects packages specified on the command line. It does not override version ranges specified in `package.json`. For example, if `package.json` specifies `"foo": "^1.0.0"` and you run `npm install --tag beta`, npm will still install a version matching `^1.0.0` even if the `beta` tag points to a different version. To install a tagged version, specify the package explicitly: `npm install foo@beta`.

327 +

328 The `--dry-run` argument will report in the usual way what the install would have done without actually installing anything.

329

330 The `--package-lock-only` argument will only update the `package-lock.json`, instead of checking `node_modules` and downloading dependencies.

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

+1 -1

@@ -52,7 +52,7 @@ Note: to get a "bottoms up" view of why a given package is included in the tree

52 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:

54 ```bash

55 -npm@11.6.4 /path/to/npm

55 +npm@11.7.0 /path/to/npm

56 └─┬ init-package-json@0.0.4

57 └── promzard@0.1.5

58 ```

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

+12 -18

@@ -40,7 +40,7 @@ redirect_from:

40 ```bash

41 npm token list

42 npm token revoke <id|token>

43 -npm token create --name=<name> [--token-description=<desc>] [--packages=<pkg1,pkg2>] [--packages-all] [--scopes=<scope1,scope2>] [--orgs=<org1,org2>] [--packages-and-scopes-permission=<read-only|read-write|no-access>] [--orgs-permission=<read-only|read-write|no-access>] [--expires=<days>] [--cidr=<ip-range>] [--bypass-2fa] [--password=<pass>]

43 +npm token create

44 ```

46 Note: This command is unaware of workspaces.

@@ -49,27 +49,21 @@ Note: This command is unaware of workspaces.

50 This lets you list, create and revoke authentication tokens.

52 -- `npm token list`: Shows a table of all active authentication tokens. You can request this as JSON with `--json` or tab-separated values with `--parseable`.

52 +#### Listing tokens

54 -```

55 -Read only token npm_1f… with id 7f3134 created 2017-10-21

56 -

57 -Publish token npm_af… with id c03241 created 2017-10-02

58 -with IP Whitelist: 192.168.0.1/24

54 +When listing tokens, an abbreviated token will be displayed. For security purposes the full token is not displayed.

60 -Publish token npm_… with id e0cf92 created 2017-10-02

56 +#### Generating tokens

62 -```

58 +When generating tokens, you will be prompted you for your password and, if you have two-factor authentication enabled, an otp.

64 -- `npm token create [--read-only] [--cidr=<cidr-ranges>]`: Create a new authentication token. It can be `--read-only`, or accept a list of [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges with which to limit use of this token. This will prompt you for your password, and, if you have two-factor authentication enabled, an otp.

60 +Please refer to the [docs website](https://docs.npmjs.com/creating-and-viewing-access-tokens) for more information on generating tokens for CI/CD.

66 - Currently, the cli cannot generate automation tokens. Please refer to the [docs website](https://docs.npmjs.com/creating-and-viewing-access-tokens) for more information on generating automation tokens.

62 +#### Revoking tokens

68 -```

69 -Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d

70 -```

64 +When revoking a token, you can use the full token (e.g. what you get back from `npm token create`, or as can be found in an `.npmrc` file), or a truncated id. If the given truncated id is not distinct enough to differentiate between multiple existing tokens, you will need to use enough of the id to allow npm to distinguish between them. Full token ids can be found on the [npm website](https://www.npmjs.com), or in the `--parseable` or `--json` output of `npm token list`. This command will NOT accept the truncated token found in the normal `npm token list` output.

72 -- `npm token revoke <token|id>`: Immediately removes an authentication token from the registry. You will no longer be able to use it. This can accept both complete tokens (such as those you get back from `npm token create`, and those found in your `.npmrc`), and ids as seen in the parseable or json output of `npm token list`. This will NOT accept the truncated token found in the normal `npm token list` output.

66 +A revoked token will immediately be removed from the registry and you will no longer be able to use it.

68 ### Configuration

@@ -99,7 +93,7 @@ When creating a Granular Access Token with `npm token create`, this sets the exp

93 - Default:

94 - Type: null or String (can be set multiple times)

102 -When creating a Granular Access Token with `npm token create`, this limits the token access to specific packages. Provide a comma-separated list of package names.

96 +When creating a Granular Access Token with `npm token create`, this limits the token access to specific packages.

98 #### `packages-all`

@@ -113,14 +107,14 @@ When creating a Granular Access Token with `npm token create`, grants the token

107 - Default: null

108 - Type: null or String (can be set multiple times)

109

116 -When creating a Granular Access Token with `npm token create`, this limits the token access to specific scopes. Provide a comma-separated list of scope names (with or without @ prefix).

110 +When creating a Granular Access Token with `npm token create`, this limits the token access to specific scopes. Provide a scope name (with or without @ prefix).

111

112 #### `orgs`

113

114 - Default: null

115 - Type: null or String (can be set multiple times)

116

123 -When creating a Granular Access Token with `npm token create`, this limits the token access to specific organizations. Provide a comma-separated list of organization names.

117 +When creating a Granular Access Token with `npm token create`, this limits the token access to specific organizations.

118

119 #### `packages-and-scopes-permission`

120

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

@@ -167,8 +167,12 @@ Run this in a package directory to bump the version and write the new data back

167

168 The `newversion` argument should be a valid semver string, a valid second argument to [semver.inc](https://github.com/npm/node-semver#functions) (one of `patch`, `minor`, `major`, `prepatch`, `preminor`, `premajor`, `prerelease`), or `from-git`. In the second case, the existing version will be incremented by 1 in the specified field. `from-git` will try to read the latest git tag, and use that as the new npm version.

169

170 +**Note:** If the current version is a prerelease version, `patch` will simply remove the prerelease suffix without incrementing the patch version number. For example, `1.2.0-5` becomes `1.2.0` with `npm version patch`, not `1.2.1`.

171 +

172 If run in a git repo, it will also create a version commit and tag. This behavior is controlled by `git-tag-version` (see below), and can be disabled on the command line by running `npm --no-git-tag-version version`. It will fail if the working directory is not clean, unless the `-f` or `--force` flag is set.

173

174 +**Note:** Git integration requires a reasonably recent version of git (2.0.0 or later is recommended). If you encounter issues with git commands, ensure your git installation is up to date.

175 +

176 If supplied with `-m` or [`--message` config](/cli/v11/using-npm/config#message) option, npm will use it as a commit message when creating a version commit. If the `message` config contains `%s` then that will be replaced with the resulting version number. For example:

177

178 ```bash

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

+64

@@ -97,6 +97,20 @@ If the field value you are querying for is a property of an object, you should r

97 npm view express time'[4.8.0]'

98 ```

100 +Note: When accessing object properties that contain special characters or numeric keys, you need to use quotes around the key name. For example, to get the publish time of a specific version:

101 +

102 +```bash

103 +npm view express "time[4.17.1]"

104 +```

105 +

106 +Without quotes, the shell may interpret the square brackets as glob patterns, causing the command to fail. You can also access the time field for a specific version by specifying the version in the package descriptor:

107 +

108 +```bash

109 +npm view express@4.17.1 time

110 +```

111 +

112 +This will return all version-time pairs, but the context will be for that specific version.

113 +

114 Multiple fields may be specified, and will be printed one after another. For example, to get all the contributor names and email addresses, you can do this:

115

116 ```bash

@@ -121,6 +135,56 @@ To show the `connect` package version history, you can do this:

135 npm view connect versions

136 ```

137

138 +### Field Access Patterns

139 +

140 +The `npm view` command supports different ways to access nested fields and array elements in package metadata. Understanding these patterns makes it easier to extract specific information.

141 +

142 +#### Nested Object Fields

143 +

144 +Use dot notation to access nested object fields:

145 +

146 +```bash

147 +# Access nested properties

148 +npm view npm repository.url

149 +npm view express bugs.url

150 +```

151 +

152 +#### Array Element Access

153 +

154 +For arrays, use numeric indices in square brackets to access specific elements:

155 +

156 +```bash

157 +# Get the first contributor's email

158 +npm view express contributors[0].email

159 +

160 +# Get the second maintainer's name

161 +npm view express maintainers[1].name

162 +```

163 +

164 +#### Object Property Access

165 +

166 +For object properties (like accessing specific versions in the `time` field), use bracket notation with the property name in quotes:

167 +

168 +```bash

169 +# Get publish time for a specific version

170 +npm view express "time[4.17.1]"

171 +

172 +# Get dist-tags

173 +npm view express "dist-tags.latest"

174 +```

175 +

176 +#### Extracting Fields from Arrays

177 +

178 +Request a non-numeric field on an array to get all values from objects in the list:

179 +

180 +```bash

181 +# Get all contributor emails

182 +npm view express contributors.email

183 +

184 +# Get all contributor names

185 +npm view express contributors.name

186 +```

187 +

188 ### Configuration

189

190 #### `json`

content/cli/v11/commands/npm.mdx

+1 -1

@@ -31,7 +31,7 @@ Note: This command is unaware of workspaces.

32 ### Version

34 -11.6.4

34 +11.7.0

36 ### Description

content/cli/v11/commands/npx.mdx

@@ -34,6 +34,8 @@ npx --package=foo -c '<cmd> [args...]'

35 This command allows you to run an arbitrary command from an npm package (either one installed locally, or fetched remotely), in a similar context as running it via `npm run`.

37 +Run this command to execute a package's binary. Any options and arguments after the package name are passed directly to the executed command, not to npx itself. For example, `npx create-react-app my-app --template typescript` will pass `my-app` and `--template typescript` to the `create-react-app` command. To see what options a specific package accepts, consult that package's documentation (e.g., at npmjs.com or in its repository).

38 +

39 Whatever packages are specified by the `--package` option will be provided in the `PATH` of the executed command, along with any locally installed package executables. The `--package` option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.

41 If any requested packages are not present in the local project dependencies, then they are installed to a folder in the npm cache, which is added to the `PATH` environment variable in the executed process. A prompt is printed (which can be suppressed by providing either `--yes` or `--no`).

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

+79

@@ -325,6 +325,12 @@ For most modules, it makes the most sense to have a main script and often not mu

325

326 If `main` is not set, it defaults to `index.js` in the package's root folder.

327

328 +### type

329 +

330 +The `type` field defines how Node.js should interpret `.js` files in your package. This field is not used by npm.

331 +

332 +See the [Node.js documentation on the type field](https://nodejs.org/api/packages.html#type) for more information.

333 +

334 ### browser

335

336 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`)

@@ -470,6 +476,19 @@ For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same

476 }

477 ```

478

479 +**Note on normalization:** When you publish a package, npm normalizes the `repository` field to the full object format with a `url` property. If you use a shorthand format (like `"npm/example"`), you'll see a warning during `npm publish` indicating that the field was auto-corrected. While the shorthand format currently works, it's recommended to use the full object format in your `package.json` to avoid warnings and ensure future compatibility:

480 +

481 +```json

482 +{

483 + "repository": {

484 + "type": "git",

485 + "url": "git+https://github.com/npm/example.git"

486 + }

487 +}

488 +```

489 +

490 +You can run `npm pkg fix` to automatically convert shorthand formats to the normalized object format.

491 +

492 If the `package.json` for your package is not in the root directory (for example if it is part of a monorepo), you can specify the directory in which it lives:

493

494 ```json

@@ -488,6 +507,20 @@ The "scripts" property is a dictionary containing script commands that are run a

507

508 See [`scripts`](/cli/v11/using-npm/scripts) to find out more about writing package scripts.

509

510 +### gypfile

511 +

512 +If you have a binding.gyp file in the root of your package and you have not defined your own `install` or `preinstall` scripts, npm will default to building your module using node-gyp.

513 +

514 +To prevent npm from automatically building your module with node-gyp, set `gypfile` to `false`:

515 +

516 +```json

517 +{

518 + "gypfile": false

519 +}

520 +```

521 +

522 +This is useful for packages that include native addons but want to handle the build process differently, or packages that have a binding.gyp file but should not be built as a native addon.

523 +

524 ### config

525

526 A "config" object can be used to set configuration parameters used in package scripts that persist across upgrades. For instance, if a package had the following:

@@ -853,6 +886,52 @@ You may not set an override for a package that you directly depend on unless bot

886 }

887 ```

888

889 +#### Replacing a dependency with a fork

890 +

891 +You can replace a package with a different package or fork using several methods:

892 +

893 +**Using the `npm:` prefix to replace with a different package name:**

894 +

895 +```json

896 +{

897 + "overrides": {

898 + "package-name": "npm:@scope/forked-package@1.0.0"

899 + }

900 +}

901 +```

902 +

903 +**Using a GitHub repository (supports branches, tags, or commit hashes):**

904 +

905 +```json

906 +{

907 + "overrides": {

908 + "package-name": "github:username/repo#branch-name"

909 + }

910 +}

911 +```

912 +

913 +**Using a local file path:**

914 +

915 +```json

916 +{

917 + "overrides": {

918 + "package-name": "file:../local-fork"

919 + }

920 +}

921 +```

922 +

923 +These replacement methods work for both top-level overrides and nested overrides. For example, to replace a transitive dependency with a fork:

924 +

925 +```json

926 +{

927 + "overrides": {

928 + "parent-package": {

929 + "vulnerable-dep": "github:username/patched-fork#v2.0.1"

930 + }

931 + }

932 +}

933 +```

934 +

935 ### engines

936

937 You can specify the version of node that your stuff works on:

content/cli/v11/configuring-npm/package-lock-json.mdx

+3 -1

@@ -136,7 +136,7 @@ npm v7 ignores this section entirely if a `packages` section is present, but doe

136

137 Dependency objects have the following fields:

138

139 -- version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it.

139 +- version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it. Note that for peer dependencies that are not installed, or optional dependencies that are not installed, this field may be omitted.

140 - bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.

141 - registry sources: This is a version number. (eg, `1.2.3`)

142 - git sources: This is a git specifier with resolved committish. (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`)

@@ -144,6 +144,8 @@ Dependency objects have the following fields:

144 - local tarball sources: This is the file URL of the tarball. (eg `file:///opt/storage/example-1.3.0.tgz`)

145 - local link sources: This is the file URL of the link. (eg `file:libs/our-module`)

146

147 + **Note:** The `version` field may be omitted for certain types of dependencies, such as optional peer dependencies that are not installed. In these cases, only metadata fields like `dev`, `optional`, and `peer` will be present.

148 +

149 - integrity: A `sha512` or `sha1` [Standard Subresource Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) string for the artifact that was unpacked in this location. For git dependencies, this is the commit sha.

150

151 - resolved: For registry sources this is path of the tarball relative to the registry URL. If the tarball URL isn't on the same server as the registry URL then this is a complete URL. `registry.npmjs.org` is a magic value meaning "the currently configured registry".

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

+11 -3

@@ -29,6 +29,14 @@ Putting `--foo bar` on the command line sets the `foo` configuration parameter t

30 Example: `--flag1 --flag2` will set both configuration parameters to `true`, while `--flag1 --flag2 bar` will set `flag1` to `true`, and `flag2` to `bar`. Finally, `--flag1 --flag2 -- bar` will set both configuration parameters to `true`, and the `bar` is taken as a command argument.

32 +**Common examples:**

33 +

34 +- `npm install --prefix /path/to/dir` - Runs npm commands in a different directory without changing the current working directory

35 +- `npm install --global` - Installs packages globally (shorthand: `-g`)

36 +- `npm install --save-dev` - Saves to devDependencies (shorthand: `-D`)

37 +

38 +Any configuration option documented in the [Config Settings](#config-settings) section below can be set via command line flags using `--option-name value` syntax.

39 +

40 #### Environment Variables

42 Any environment variables that start with `npm_config_` will be interpreted as a configuration parameter. For example, putting `npm_config_foo=bar` in your environment will set the `foo` configuration parameter to `bar`. Any environment configurations that are not given a value will be given the value of `true`. Config values are case-insensitive, so `NPM_CONFIG_FOO=bar` will work the same. However, please note that inside [`scripts`](/cli/v11/using-npm/scripts) npm will set its own environment variables and Node will prefer those lowercase versions over any uppercase ones that you might set. For details see [this issue](https://github.com/npm/npm/issues/14528).

@@ -836,7 +844,7 @@ This option causes npm to create lock files without a `resolved` key for registr

844 - Default: null

845 - Type: null or String (can be set multiple times)

846

839 -When creating a Granular Access Token with `npm token create`, this limits the token access to specific organizations. Provide a comma-separated list of organization names.

847 +When creating a Granular Access Token with `npm token create`, this limits the token access to specific organizations.

848

849 #### `orgs-permission`

850

@@ -898,7 +906,7 @@ For `list` this means the output will be based on the tree described by the `pac

906 - Default:

907 - Type: null or String (can be set multiple times)

908

901 -When creating a Granular Access Token with `npm token create`, this limits the token access to specific packages. Provide a comma-separated list of package names.

909 +When creating a Granular Access Token with `npm token create`, this limits the token access to specific packages.

910

911 #### `packages-all`

912

@@ -1149,7 +1157,7 @@ npm init --scope=@foo --yes

1157 - Default: null

1158 - Type: null or String (can be set multiple times)

1159

1152 -When creating a Granular Access Token with `npm token create`, this limits the token access to specific scopes. Provide a comma-separated list of scope names (with or without @ prefix).

1160 +When creating a Granular Access Token with `npm token create`, this limits the token access to specific scopes. Provide a scope name (with or without @ prefix).

1161

1162 #### `script-shell`

1163

content/cli/v11/using-npm/package-spec.mdx

+3 -3

@@ -48,9 +48,9 @@ See `Package name` above for more info on referring to a package by name, and [r

49 Examples:

51 -- `semver:@npm:@npmcli/semver-with-patch`

52 -- `semver:@npm:semver@7.2.2`

53 -- `semver:@npm:semver@legacy`

51 +- `semver@npm:@npmcli/semver-with-patch`

52 +- `semver@npm:semver@7.2.2`

53 +- `semver@npm:semver@legacy`

55 ### Folders

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

+35 -13

@@ -46,7 +46,7 @@ There are some special life cycle scripts that happen only in certain situations

46 **prepare** (since `npm@4.0.0`)

48 - Runs BEFORE the package is packed, i.e. during `npm publish` and `npm pack`

49 -- Runs on local `npm install` without any arguments

49 +- Runs on local `npm install` without package arguments (runs with flags like `--production` or `--omit=dev`, but does not run when installing specific packages like `npm install express`)

50 - Runs AFTER `prepublishOnly` and `prepack`, but BEFORE `postpack`

51 - Runs for a package if it's being installed as a link through `npm install <folder>`

@@ -54,6 +54,8 @@ There are some special life cycle scripts that happen only in certain situations

55 - As of `npm@7` these scripts run in the background. To see the output, run with: `--foreground-scripts`.

57 +- **In workspaces, prepare scripts run concurrently** across all packages. If you have interdependent packages where one must build before another, consider using `--foreground-scripts` (which can be set in `.npmrc` with `foreground-scripts=true`) to run scripts sequentially, or structure your build differently.

58 +

59 **prepublish** (DEPRECATED)

61 - Does not run during `npm publish`, but does run during `npm ci` and `npm install`. See below for more info.

@@ -86,15 +88,15 @@ See [https://github.com/npm/npm/issues/10074](https://github.com/npm/npm/issues/

89 **Use Cases**

89 -If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a `prepublish` script. This includes tasks such as:

91 +Use a `prepare` script to perform build tasks that are platform-independent and need to run before your package is used. This includes tasks such as:

91 -- Compiling CoffeeScript source code into JavaScript.

93 +- Compiling TypeScript or other source code into JavaScript.

94 - Creating minified versions of JavaScript source code.

95 - Fetching remote resources that your package will use.

95 -The advantage of doing these things at `prepublish` time is that they can be done once, in a single place, thus reducing complexity and variability. Additionally, this means that:

97 +Running these build tasks in the `prepare` script ensures they happen once, in a single place, reducing complexity and variability. Additionally, this means that:

97 -- You can depend on `coffee-script` as a `devDependency`, and thus your users don't need to have it installed.

99 +- You can depend on build tools as `devDependencies`, and thus your users don't need to have them installed.

100 - You don't need to include minifiers in your package, reducing the size for your users.

101 - You don't need to rely on your users having `curl` or `wget` or other system tools on the target machines.

102

@@ -261,7 +263,27 @@ then you could run `npm start` to execute the `bar` script, which is exported in

263

264 #### package.json vars

265

264 -The package.json fields are tacked onto the `npm_package_` prefix. So, for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your package.json file, then your package scripts would have the `npm_package_name` environment variable set to "foo", and the `npm_package_version` set to "1.2.5". You can access these variables in your code with `process.env.npm_package_name` and `process.env.npm_package_version`, and so on for other fields.

266 +npm sets the following environment variables from the package.json:

267 +

268 +- `npm_package_name` - The package name

269 +- `npm_package_version` - The package version

270 +- `npm_package_bin_*` - Each executable defined in the bin field

271 +- `npm_package_engines_*` - Each engine defined in the engines field

272 +- `npm_package_config_*` - Each config value defined in the config field

273 +- `npm_package_json` - The full path to the package.json file

274 +

275 +Additionally, for install scripts (`preinstall`, `install`, `postinstall`), npm sets these environment variables:

276 +

277 +- `npm_package_resolved` - The resolved URL for the package

278 +- `npm_package_integrity` - The integrity hash for the package

279 +- `npm_package_optional` - Set to `"true"` if the package is optional

280 +- `npm_package_dev` - Set to `"true"` if the package is a dev dependency

281 +- `npm_package_peer` - Set to `"true"` if the package is a peer dependency

282 +- `npm_package_dev_optional` - Set to `"true"` if the package is both dev and optional

283 +

284 +For example, if you had `{"name":"foo", "version":"1.2.5"}` in your package.json file, then your package scripts would have the `npm_package_name` environment variable set to "foo", and the `npm_package_version` set to "1.2.5". You can access these variables in your code with `process.env.npm_package_name` and `process.env.npm_package_version`.

285 +

286 +**Note:** In npm 7 and later, most package.json fields are no longer provided as environment variables. Scripts that need access to other package.json fields should read the package.json file directly. The `npm_package_json` environment variable provides the path to the file for this purpose.

287

288 See [`package.json`](/cli/v11/configuring-npm/package-json) for more on package configs.

289

@@ -282,22 +304,22 @@ For example, if your package.json contains this:

304 ```json

305 {

306 "scripts": {

285 - "install": "scripts/install.js",

286 - "postinstall": "scripts/install.js"

307 + "prepare": "scripts/build.js",

308 + "test": "scripts/test.js"

309 }

310 }

311 ```

312

291 -then `scripts/install.js` will be called for the install and post-install stages of the lifecycle. Since `scripts/install.js` is running for two different phases, it would be wise in this case to look at the `npm_lifecycle_event` environment variable.

313 +then `scripts/build.js` will be called for the prepare stage of the lifecycle, and you can check the `npm_lifecycle_event` environment variable if your script needs to behave differently in different contexts.

314

293 -If you want to run a make command, you can do so. This works just fine:

315 +If you want to run build commands, you can do so. This works just fine:

316

317 ```json

318 {

319 "scripts": {

298 - "preinstall": "./configure",

299 - "install": "make && make install",

300 - "test": "make test"

320 + "prepare": "npm run build",

321 + "build": "tsc",

322 + "test": "jest"

323 }

324 }

325 ```

content/nav.yml

+1 -1

@@ -1596,7 +1596,7 @@

1596 - title: Changelog

1597 url: /cli/v10/using-npm/changelog

1598 description: Changelog notes for each version

1599 - - title: Version 11.6.4

1599 + - title: Version 11.7.0

1600 shortName: v11

1601 url: /cli/v11

1602 default: true