@cryptotaxi247 / documentation-1 / commits / 3150a97

CLI documentation update from CI

npm CLI robot committed May 20, 2026 at 20:38 UTC 3150a97601c09d3b95374bbe2e267e560e0cc7b7
11 files changed +271 -27
cli-cache.json
+1 -1
@@ -2,5 +2,5 @@
2 "v8": "aa8fff11cdab94fff1a2160ee5241f5f4632e96b",
3 "v9": "64763a341e7aa5b456e696f956759bf9b3440dc1",
4 "v10": "189ba136a75c773927a5cb8922e6b00c71814d35",
5 - "v11": "c97b39b1e3436cd20a67ab5f4012a5f395c538b9"
5 + "v11": "f502c4f07fb14eef041f4dfb04ad5d9f287c6ba4"
6 }
\ No newline at end of file
content/cli/v11/commands/npm-install-test.mdx
+2 -4
@@ -231,7 +231,7 @@ If passed to `npm install`, will rebuild the npm tree such that only versions th
231
232 If the requested version is a `dist-tag` and the given tag does not pass the `--before` filter, the most recent version less than or equal to that tag will be used. For example, `foo@latest` might install `foo@1.2` even though `latest` is `2.0`.
233
234 -This config cannot be used with: `min-release-age`
234 +If `before` and `min-release-age` are both set in the same source, `before` wins (an explicit absolute date overrides a relative window). Across sources, the standard precedence applies (cli > env > project > user > global), so a higher-priority source can always relax or override a lower-priority one.
235
236 #### `min-release-age`
237
@@ -240,9 +240,7 @@ This config cannot be used with: `min-release-age`
240
241 If set, npm will build the npm tree such that only versions that were available more than the given number of days ago will be installed. If there are no versions available for the current set of dependencies, the command will error.
242
243 -This flag is a complement to `before`, which accepts an exact date instead of a relative number of days.
244 -
245 -This config cannot be used with: `before`
243 +This flag is a complement to `before`, which accepts an exact date instead of a relative number of days. The two may coexist (e.g. `min-release-age` in your `.npmrc` is preserved when npm internally spawns a sub-process with `--before` while preparing a `git:` or `github:` dependency); when both apply, `before` wins within a single source and across sources the standard precedence rules apply.
244
245 This value is not exported to the environment for child processes.
246
content/cli/v11/commands/npm-install.mdx
+2 -4
@@ -535,7 +535,7 @@ If passed to `npm install`, will rebuild the npm tree such that only versions th
535
536 If the requested version is a `dist-tag` and the given tag does not pass the `--before` filter, the most recent version less than or equal to that tag will be used. For example, `foo@latest` might install `foo@1.2` even though `latest` is `2.0`.
537
538 -This config cannot be used with: `min-release-age`
538 +If `before` and `min-release-age` are both set in the same source, `before` wins (an explicit absolute date overrides a relative window). Across sources, the standard precedence applies (cli > env > project > user > global), so a higher-priority source can always relax or override a lower-priority one.
539
540 #### `min-release-age`
541
@@ -544,9 +544,7 @@ This config cannot be used with: `min-release-age`
544
545 If set, npm will build the npm tree such that only versions that were available more than the given number of days ago will be installed. If there are no versions available for the current set of dependencies, the command will error.
546
547 -This flag is a complement to `before`, which accepts an exact date instead of a relative number of days.
548 -
549 -This config cannot be used with: `before`
547 +This flag is a complement to `before`, which accepts an exact date instead of a relative number of days. The two may coexist (e.g. `min-release-age` in your `.npmrc` is preserved when npm internally spawns a sub-process with `--before` while preparing a `git:` or `github:` dependency); when both apply, `before` wins within a single source and across sources the standard precedence rules apply.
548
549 This value is not exported to the environment for child processes.
550
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:
53
54 ```bash
55 -npm@11.14.1 /path/to/npm
55 +npm@11.15.0 /path/to/npm
56 └─┬ init-package-json@0.0.4
57 └── promzard@0.1.5
58 ```
content/cli/v11/commands/npm-outdated.mdx
+2 -4
@@ -160,7 +160,7 @@ If passed to `npm install`, will rebuild the npm tree such that only versions th
160
161 If the requested version is a `dist-tag` and the given tag does not pass the `--before` filter, the most recent version less than or equal to that tag will be used. For example, `foo@latest` might install `foo@1.2` even though `latest` is `2.0`.
162
163 -This config cannot be used with: `min-release-age`
163 +If `before` and `min-release-age` are both set in the same source, `before` wins (an explicit absolute date overrides a relative window). Across sources, the standard precedence applies (cli > env > project > user > global), so a higher-priority source can always relax or override a lower-priority one.
164
165 #### `min-release-age`
166
@@ -169,9 +169,7 @@ This config cannot be used with: `min-release-age`
169
170 If set, npm will build the npm tree such that only versions that were available more than the given number of days ago will be installed. If there are no versions available for the current set of dependencies, the command will error.
171
172 -This flag is a complement to `before`, which accepts an exact date instead of a relative number of days.
173 -
174 -This config cannot be used with: `before`
172 +This flag is a complement to `before`, which accepts an exact date instead of a relative number of days. The two may coexist (e.g. `min-release-age` in your `.npmrc` is preserved when npm internally spawns a sub-process with `--before` while preparing a `git:` or `github:` dependency); when both apply, `before` wins within a single source and across sources the standard precedence rules apply.
173
174 This value is not exported to the environment for child processes.
175
content/cli/v11/commands/npm-stage.mdx new
+234
@@ -0,0 +1,234 @@
1 +---
2 +title: npm-stage
3 +section: 1
4 +description: Stage packages for publishing
5 +github_repo: npm/cli
6 +github_branch: latest
7 +github_path: docs/lib/content/commands/npm-stage.md
8 +redirect_from:
9 + - /cli-commands/npm-stage
10 + - /cli-commands/stage
11 + - /cli-documentation/cli-commands/npm-stage
12 + - /cli-documentation/cli-commands/stage
13 + - /cli-documentation/commands/npm-stage
14 + - /cli-documentation/commands/stage
15 + - /cli-documentation/npm-stage
16 + - /cli-documentation/stage
17 + - /cli-documentation/v11/cli-commands/npm-stage
18 + - /cli-documentation/v11/cli-commands/stage
19 + - /cli-documentation/v11/commands/npm-stage
20 + - /cli-documentation/v11/commands/stage
21 + - /cli-documentation/v11/npm-stage
22 + - /cli-documentation/v11/stage
23 + - /cli/cli-commands/npm-stage
24 + - /cli/cli-commands/stage
25 + - /cli/commands/npm-stage
26 + - /cli/commands/stage
27 + - /cli/npm-stage
28 + - /cli/stage
29 + - /cli/v11/cli-commands/npm-stage
30 + - /cli/v11/cli-commands/stage
31 + - /cli/v11/commands/stage
32 + - /cli/v11/npm-stage
33 + - /cli/v11/stage
34 + - /commands/npm-stage
35 + - /commands/stage
36 +---
37 +
38 +### Synopsis
39 +
40 +```bash
41 +npm stage
42 +```
43 +
44 +Note: This command is unaware of workspaces.
45 +
46 +### Description
47 +
48 +Staged publishing allows package maintainers to require proof-of-presence for all publishes. Proof-of-presence is where a human is involved, interjects, and provides authentication (2FA) during an action — in this case, publishing an npm package.
49 +
50 +Typically when maintainers use automated workflows to publish, proof-of-presence is lacking as there's no convenient way to interject the process and provide 2FA, as is the case for publishing with a granular access token with bypass and the trusted publishing flow. Staged publishing allows users to have their automated workflows stage a package without a 2FA prompt, deferring the act of 2FA, allowing the maintainer to approve the staged package and publish at a later point.
51 +
52 +The `npm stage publish` command packs the current working directory and places that version of the package into the registry in a state where it's not available for public access, allowing maintainers to approve the package at a later point in time. The act of staging does not prompt for 2FA and can be done with any token type, the act of approving will.
53 +
54 +Key behaviors:
55 +
56 +- Staged packages share the same semver version unique index as published packages — you cannot publish a version that already exists as a staged version for that package.
57 +- You can still publish packages normally while you have staged packages pending.
58 +- You can stage multiple versions of the same package.
59 +- `npm stage publish` has parity with `npm publish` and will respect `"private": true` in `package.json`, refusing to stage the package.
60 +
61 +### Prerequisites
62 +
63 +Before using `npm stage` commands, ensure the following requirements are met:
64 +
65 +- **Write permissions on the package:** You must have write access to the package you're configuring.
66 +- **Package must exist:** The package you're configuring must already exist on the npm registry.
67 +- **2FA enabled on your account:** Commands that require 2FA will prompt you to authenticate. If you don't already have 2FA enabled on your account, you must enable it before using these commands.
68 +
69 +### Subcommands
70 +
71 +- `npm stage publish [<package-spec>]` - Stage a package for publishing
72 +- `npm stage list [<package-spec>]` - List all staged package versions
73 +- `npm stage view <stage-id>` - View details of a specific staged package
74 +- `npm stage approve <stage-id>` - Approve a staged package for publishing
75 +- `npm stage reject <stage-id>` - Reject a staged package
76 +- `npm stage download <stage-id>` - Download the tarball for inspection
77 +
78 +### 2FA Requirements by Subcommand
79 +
80 +| Command | Requires 2FA | Notes |
81 +| --- | --- | --- |
82 +| `npm stage publish` | No | Designed for automated workflows; defers 2FA to approval |
83 +| `npm stage list` | No | View staged packages |
84 +| `npm stage view` | No | View staged package details |
85 +| `npm stage approve` | Yes | Prompts for 2FA to publish the staged package |
86 +| `npm stage reject` | Yes | Prompts for 2FA to permanently remove the staged package |
87 +| `npm stage download` | No | Downloads the tarball for local inspection |
88 +
89 +### Tag Behavior
90 +
91 +The `--tag` flag follows the same logic as `npm publish`. If no tag is provided, the `latest` tag is used by default. For pre-release versions (e.g., `1.0.0-beta.1`) and non-latest semver versions, the tag must be explicitly provided — otherwise the CLI will error, just as `npm publish` would.
92 +
93 +The tag is an immutable property of the staged package. Once a package is staged with a given tag, the tag cannot be changed. If you need to stage the same version with a different tag, you must first reject the existing staged package using `npm stage reject` and then re-stage it with the desired tag.
94 +
95 +### Token Behavior
96 +
97 +The key difference with staged publishing is that `npm stage publish` never requires a 2FA prompt, regardless of token type. This is what makes it suitable for automated workflows. The goal of `npm stage publish` is deferring proof-of-presence to a later point in time.
98 +
99 +| Token Type | `npm stage publish` | `npm publish` |
100 +| --- | --- | --- |
101 +| GAT with bypass | Can stage | Can publish (if allowed by package publishing access) |
102 +| GAT without bypass | Can stage | 2FA prompt (if allowed by package publishing access) |
103 +| Session token | Can stage | 2FA prompt |
104 +| Trust token (OIDC) | Can stage (if allowed) | Can publish (if allowed) |
105 +
106 +### Trust Relationship Permissions
107 +
108 +With staged publishing, trust relationships now support granular command permissions. Shortlived tokens issued through trust relationships can only be used with `npm stage publish` and `npm publish`. Shortlived tokens cannot run `npm stage` subcommands.
109 +
110 +`npm trust <provider>` supports `--allow-publish` and `--allow-stage-publish` to control which commands are available through each trust relationship.
111 +
112 +### Best Practices
113 +
114 +**Note:** The addition of staged publishing does not make your account or org more secure. Maintainers must still use the best practices listed below.
115 +
116 +1. **Delete Granular Access Tokens (GAT) with bypass 2FA enabled.** Now with staged publishing, we've eliminated the need for a GAT token that can bypass 2FA. We encourage you to delete all your tokens with bypass enabled and switch to using a trust relationship in your automated workflows, or create a GAT without bypass and use `npm stage publish`.
117 +
118 +2. **Disallow tokens from publishing at the package level.** All packages have their own access controls under "package access" allowing packages to be published with bypass tokens, which is no longer a necessity. We encourage you to select "Require two-factor authentication and disallow tokens (recommended)" for all your packages on the package access page.
119 +
120 +3. **Configure trust relationship permissions to prevent `npm publish`.** We encourage you to only enable `npm stage publish` on your trust relationships and disable `npm publish`.
121 +
122 +### Configuration
123 +
124 +### `npm stage publish`
125 +
126 +Stage a package for publishing, deferring proof-of-presence (2FA) to a later point in time
127 +
128 +#### Synopsis
129 +
130 +```bash
131 +npm stage publish <package-spec>
132 +```
133 +
134 +#### Flags
135 +
136 +| Flag | Default | Type | Description |
137 +| --- | --- | --- | --- |
138 +| `--tag` | "latest" | String | If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag. It is the tag added to the package@version specified in the `npm dist-tag add` command, if no explicit tag is given. When used by the `npm diff` command, this is the tag used to fetch the tarball that will be compared with the local files by default. If used in the `npm publish` command, this is the tag that will be added to the package submitted to the registry. |
139 +| `--access` |
140 +
141 + 'public' for new packages, existing packages it will not change the current level
142 +
143 +| null, "restricted", or "public" | If you do not want your scoped package to be publicly viewable (and installable) set `--access=restricted`. Unscoped packages cannot be set to `restricted`. Note: This defaults to not changing the current access level for existing packages. Specifying a value of `restricted` or `public` during publish will change the access for an existing package the same way that `npm access set status` would. | | `--dry-run` | false | Boolean | Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`. Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc. | | `--otp` | null | null or String | This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`. If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one. | | `--workspace`, `-w` | | String (can be set multiple times) | Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option. Valid values for the `workspace` config are either: _ Workspace names _ Path to a workspace directory \* Path to a parent workspace directory (will result in selecting all workspaces within that folder) When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project. | | `--workspaces` | null | null or Boolean | Set to true to run the command in the context of **all** configured workspaces. Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly: - Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config. | | `--include-workspace-root` | false | Boolean | Include the workspace root when workspaces are enabled for a command. When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project. | | `--provenance` | false | Boolean | When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from. |
144 +
145 +### `npm stage list`
146 +
147 +List all staged package versions
148 +
149 +#### Synopsis
150 +
151 +```bash
152 +npm stage list [<package-spec>]
153 +```
154 +
155 +#### Flags
156 +
157 +| Flag | Default | Type | Description |
158 +| --- | --- | --- | --- |
159 +| `--json` | false | Boolean | Whether or not to output JSON data, rather than the normal output. \* In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`. Not supported by all npm commands. |
160 +| `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
161 +
162 +### `npm stage view`
163 +
164 +View details of a specific staged package
165 +
166 +#### Synopsis
167 +
168 +```bash
169 +npm stage view <stage-id>
170 +```
171 +
172 +#### Flags
173 +
174 +| Flag | Default | Type | Description |
175 +| --- | --- | --- | --- |
176 +| `--json` | false | Boolean | Whether or not to output JSON data, rather than the normal output. \* In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`. Not supported by all npm commands. |
177 +| `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
178 +
179 +### `npm stage approve`
180 +
181 +Approve a staged package, publishing it to the npm registry
182 +
183 +#### Synopsis
184 +
185 +```bash
186 +npm stage approve <stage-id>
187 +```
188 +
189 +#### Flags
190 +
191 +| Flag | Default | Type | Description |
192 +| --- | --- | --- | --- |
193 +| `--otp` | null | null or String | This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`. If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one. |
194 +| `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
195 +
196 +### `npm stage reject`
197 +
198 +Reject a staged package, removing it from the registry
199 +
200 +#### Synopsis
201 +
202 +```bash
203 +npm stage reject <stage-id>
204 +```
205 +
206 +#### Flags
207 +
208 +| Flag | Default | Type | Description |
209 +| --- | --- | --- | --- |
210 +| `--otp` | null | null or String | This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`. If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one. |
211 +| `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
212 +
213 +### `npm stage download`
214 +
215 +Download the tarball of a staged package for inspection
216 +
217 +#### Synopsis
218 +
219 +```bash
220 +npm stage download <stage-id>
221 +```
222 +
223 +#### Flags
224 +
225 +| Flag | Default | Type | Description |
226 +| --- | --- | --- | --- |
227 +| `--json` | false | Boolean | Whether or not to output JSON data, rather than the normal output. \* In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`. Not supported by all npm commands. |
228 +| `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
229 +
230 +### See Also
231 +
232 +- [npm publish](/cli/v11/commands/npm-publish)
233 +- [npm unpublish](/cli/v11/commands/npm-unpublish)
234 +- [npm trust](/cli/v11/commands/npm-trust)
content/cli/v11/commands/npm-trust.mdx
+20 -3
@@ -59,6 +59,17 @@ The `[package]` argument specifies the package name. If omitted, npm will use th
59
60 Each trust relationship has its own set of configuration options and flags based on the OIDC claims provided by that provider. OIDC claims come from the CI/CD provider and include information such as repository name, workflow file, or environment. Since each provider's claims differ, the available flags and configuration keys are not universal—npm matches the claims supported by each provider's OIDC configuration. For specific details on which claims and flags are supported for a given provider, use `npm trust <provider> --help`.
61
62 +### Permissions
63 +
64 +When creating a trust relationship, you must specify at least one permission flag to indicate which operations the trusted publisher is allowed to perform:
65 +
66 +- `--allow-publish`: Allows the trusted publisher to run `npm publish` for the package.
67 +- `--allow-stage-publish`: Allows the trusted publisher to run `npm stage` for the package. The alias `--allow-staged-publish` is also accepted.
68 +
69 +At least one of these flags is required when creating a trust configuration. You can specify both to grant both permissions.
70 +
71 +### Provider Options
72 +
73 The required options depend on the CI/CD provider you're configuring. Detailed information about each option is available in the [managing trusted publisher configurations](https://docs.npmjs.com/trusted-publishers#managing-trusted-publisher-configurations) section of the npm documentation. If a provider is repository-based and the option is not provided, npm will use the `repository.url` field from your `package.json`, if available.
74
75 Currently, the registry only supports one configuration per package. If you attempt to create a new trust relationship when one already exists, it will result in an error. To replace an existing configuration:
@@ -84,7 +95,7 @@ Create a trusted relationship between a package and GitHub Actions
95 #### Synopsis
96
97 ```bash
87 -npm trust github [package] --file [--repo|--repository] [--env|--environment] [-y|--yes]
98 +npm trust github [package] --file [--repo|--repository] [--env|--environment] [--allow-publish] [--allow-stage-publish] [-y|--yes]
99 ```
100
101 #### Flags
@@ -94,6 +105,8 @@ npm trust github [package] --file [--repo|--repository] [--env|--environment] [-
105 | `--file` | null | String (required) | Name of workflow file within a repositories .GitHub folder (must end in yaml, yml) |
106 | `--repository`, `--repo` | null | String | Name of the repository in the format owner/repo |
107 | `--environment`, `--env` | null | String | CI environment name |
108 +| `--allow-publish` | false | Boolean | Allow npm publish for this trusted publisher configuration |
109 +| `--allow-stage-publish`, `--allow-staged-publish` | false | Boolean | Allow npm stage publish for this trusted publisher configuration |
110 | `--dry-run` | false | Boolean | Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`. Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc. |
111 | `--json` | false | Boolean | Whether or not to output JSON data, rather than the normal output. \* In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`. Not supported by all npm commands. |
112 | `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
@@ -106,7 +119,7 @@ Create a trusted relationship between a package and GitLab CI/CD
119 #### Synopsis
120
121 ```bash
109 -npm trust gitlab [package] --file [--project|--repo|--repository] [--env|--environment] [-y|--yes]
122 +npm trust gitlab [package] --file [--project|--repo|--repository] [--env|--environment] [--allow-publish] [--allow-stage-publish] [-y|--yes]
123 ```
124
125 #### Flags
@@ -116,6 +129,8 @@ npm trust gitlab [package] --file [--project|--repo|--repository] [--env|--envir
129 | `--file` | null | String (required) | Name of pipeline file (e.g., .gitlab-ci.yml) |
130 | `--project` | null | String | Name of the project in the format group/project or group/subgroup/project |
131 | `--environment`, `--env` | null | String | CI environment name |
132 +| `--allow-publish` | false | Boolean | Allow npm publish for this trusted publisher configuration |
133 +| `--allow-stage-publish`, `--allow-staged-publish` | false | Boolean | Allow npm stage publish for this trusted publisher configuration |
134 | `--dry-run` | false | Boolean | Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`. Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc. |
135 | `--json` | false | Boolean | Whether or not to output JSON data, rather than the normal output. \* In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`. Not supported by all npm commands. |
136 | `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
@@ -128,7 +143,7 @@ Create a trusted relationship between a package and CircleCI
143 #### Synopsis
144
145 ```bash
131 -npm trust circleci [package] --org-id <uuid> --project-id <uuid> --pipeline-definition-id <uuid> --vcs-origin <origin> [--context-id <uuid>...] [-y|--yes]
146 +npm trust circleci [package] --org-id <uuid> --project-id <uuid> --pipeline-definition-id <uuid> --vcs-origin <origin> [--context-id <uuid>...] [--allow-publish] [--allow-stage-publish] [-y|--yes]
147 ```
148
149 #### Flags
@@ -140,6 +155,8 @@ npm trust circleci [package] --org-id <uuid> --project-id <uuid> --pipeline-defi
155 | `--pipeline-definition-id` | null | String (required) | CircleCI pipeline definition UUID |
156 | `--vcs-origin` | null | String (required) | CircleCI repository origin in format 'provider/owner/repo' |
157 | `--context-id` | null | null or String (can be set multiple times) | CircleCI context UUID to match |
158 +| `--allow-publish` | false | Boolean | Allow npm publish for this trusted publisher configuration |
159 +| `--allow-stage-publish`, `--allow-staged-publish` | false | Boolean | Allow npm stage publish for this trusted publisher configuration |
160 | `--dry-run` | false | Boolean | Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`. Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc. |
161 | `--json` | false | Boolean | Whether or not to output JSON data, rather than the normal output. \* In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`. Not supported by all npm commands. |
162 | `--registry` | "https://registry.npmjs.org/" | URL | The base URL of the npm registry. |
content/cli/v11/commands/npm-update.mdx
+2 -4
@@ -280,7 +280,7 @@ If passed to `npm install`, will rebuild the npm tree such that only versions th
280
281 If the requested version is a `dist-tag` and the given tag does not pass the `--before` filter, the most recent version less than or equal to that tag will be used. For example, `foo@latest` might install `foo@1.2` even though `latest` is `2.0`.
282
283 -This config cannot be used with: `min-release-age`
283 +If `before` and `min-release-age` are both set in the same source, `before` wins (an explicit absolute date overrides a relative window). Across sources, the standard precedence applies (cli > env > project > user > global), so a higher-priority source can always relax or override a lower-priority one.
284
285 #### `min-release-age`
286
@@ -289,9 +289,7 @@ This config cannot be used with: `min-release-age`
289
290 If set, npm will build the npm tree such that only versions that were available more than the given number of days ago will be installed. If there are no versions available for the current set of dependencies, the command will error.
291
292 -This flag is a complement to `before`, which accepts an exact date instead of a relative number of days.
293 -
294 -This config cannot be used with: `before`
292 +This flag is a complement to `before`, which accepts an exact date instead of a relative number of days. The two may coexist (e.g. `min-release-age` in your `.npmrc` is preserved when npm internally spawns a sub-process with `--before` while preparing a `git:` or `github:` dependency); when both apply, `before` wins within a single source and across sources the standard precedence rules apply.
293
294 This value is not exported to the environment for child processes.
295
content/cli/v11/commands/npm.mdx
+1 -1
@@ -31,7 +31,7 @@ Note: This command is unaware of workspaces.
31
32 ### Version
33
34 -11.14.1
34 +11.15.0
35
36 ### Description
37
content/cli/v11/using-npm/config.mdx
+2 -4
@@ -223,7 +223,7 @@ If passed to `npm install`, will rebuild the npm tree such that only versions th
223
224 If the requested version is a `dist-tag` and the given tag does not pass the `--before` filter, the most recent version less than or equal to that tag will be used. For example, `foo@latest` might install `foo@1.2` even though `latest` is `2.0`.
225
226 -This config cannot be used with: `min-release-age`
226 +If `before` and `min-release-age` are both set in the same source, `before` wins (an explicit absolute date overrides a relative window). Across sources, the standard precedence applies (cli > env > project > user > global), so a higher-priority source can always relax or override a lower-priority one.
227
228 #### `bin-links`
229
@@ -832,9 +832,7 @@ Any "%s" in the message will be replaced with the version number.
832
833 If set, npm will build the npm tree such that only versions that were available more than the given number of days ago will be installed. If there are no versions available for the current set of dependencies, the command will error.
834
835 -This flag is a complement to `before`, which accepts an exact date instead of a relative number of days.
836 -
837 -This config cannot be used with: `before`
835 +This flag is a complement to `before`, which accepts an exact date instead of a relative number of days. The two may coexist (e.g. `min-release-age` in your `.npmrc` is preserved when npm internally spawns a sub-process with `--before` while preparing a `git:` or `github:` dependency); when both apply, `before` wins within a single source and across sources the standard precedence rules apply.
836
837 This value is not exported to the environment for child processes.
838
content/nav.yml
+4 -1
@@ -1598,7 +1598,7 @@
1598 - title: Changelog
1599 url: /cli/v10/using-npm/changelog
1600 description: Changelog notes for each version
1601 - - title: Version 11.14.1
1601 + - title: Version 11.15.0
1602 shortName: v11
1603 url: /cli/v11
1604 default: true
@@ -1761,6 +1761,9 @@
1761 - title: npm set
1762 url: /cli/v11/commands/npm-set
1763 description: Set a value in the npm configuration
1764 + - title: npm stage
1765 + url: /cli/v11/commands/npm-stage
1766 + description: Stage packages for publishing
1767 - title: npm start
1768 url: /cli/v11/commands/npm-start
1769 description: Start a package