| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
1 parent c9153c7 commit 27da9ca
204 files changed
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -99,6 +99,8 @@ Even if you never publish your package, you can still get a lot of benefits of u | |||
| 99 | 99 | ||
| 100 | 100 | In most cases, this will install the version of the modules tagged as `latest` on the npm registry. | |
| 101 | 101 | ||
| 102 | + **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`. | ||
| 103 | + | ||
| 102 | 104 | Example: | |
| 103 | 105 | ||
| 104 | 106 | ```bash | |
@@ -202,6 +204,15 @@ Even if you never publish your package, you can still get a lot of benefits of u | |||
| 202 | 204 | npm install @myorg/privatepackage@"16 - 17" | |
| 203 | 205 | ``` | |
| 204 | 206 | ||
| 207 | + **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. | ||
| 208 | + | ||
| 209 | + Example: | ||
| 210 | + | ||
| 211 | + ```bash | ||
| 212 | + 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. | ||
| 213 | + npm install package@^1.0.0-0 # Matches all 1.x.x prereleases and stable versions | ||
| 214 | + ``` | ||
| 215 | + | ||
| 205 | 216 | * `npm install <git remote url>`: | |
| 206 | 217 | ||
| 207 | 218 | Installs the package from the hosted git provider, cloning it with `git`. | |
@@ -319,6 +330,8 @@ npm install sax@">=0.1.0 <0.2.0" bench supervisor | |||
| 319 | 330 | The `--tag` argument will apply to all of the specified install targets. | |
| 320 | 331 | If a tag with the given name exists, the tagged version is preferred over newer versions. | |
| 321 | 332 | ||
| 333 | + **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`. | ||
| 334 | + | ||
| 322 | 335 | The `--dry-run` argument will report in the usual way what the install would have done without actually installing anything. | |
| 323 | 336 | ||
| 324 | 337 | The `--package-lock-only` argument will only update the `package-lock.json`, instead of checking `node_modules` and downloading dependencies. | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -23,7 +23,7 @@ Note that nested packages will *also* show the paths to the specified packages. | |||
| 23 | 23 | For example, running `npm ls promzard` in npm's source tree will show: | |
| 24 | 24 | ||
| 25 | 25 | ```bash | |
| 26 | - npm@11.6.4 /path/to/npm | ||
| 26 | + npm@11.7.0 /path/to/npm | ||
| 27 | 27 | └─┬ init-package-json@0.0.4 | |
| 28 | 28 | └── promzard@0.1.5 | |
| 29 | 29 | ``` | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -9,7 +9,7 @@ description: Manage your authentication tokens | |||
| 9 | 9 | ```bash | |
| 10 | 10 | npm token list | |
| 11 | 11 | npm token revoke <id|token> | |
| 12 | - 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>] | ||
| 12 | + npm token create | ||
| 13 | 13 | ``` | |
| 14 | 14 | ||
| 15 | 15 | Note: This command is unaware of workspaces. | |
@@ -18,37 +18,21 @@ Note: This command is unaware of workspaces. | |||
| 18 | 18 | ||
| 19 | 19 | This lets you list, create and revoke authentication tokens. | |
| 20 | 20 | ||
| 21 | - * `npm token list`: | ||
| 22 | - Shows a table of all active authentication tokens. | ||
| 23 | - You can request this as JSON with `--json` or tab-separated values with `--parseable`. | ||
| 21 | + #### Listing tokens | ||
| 24 | 22 | ||
| 25 | - ``` | ||
| 26 | - Read only token npm_1f… with id 7f3134 created 2017-10-21 | ||
| 27 | - | ||
| 28 | - Publish token npm_af… with id c03241 created 2017-10-02 | ||
| 29 | - with IP Whitelist: 192.168.0.1/24 | ||
| 23 | + When listing tokens, an abbreviated token will be displayed. For security purposes the full token is not displayed. | ||
| 30 | 24 | ||
| 31 | - Publish token npm_… with id e0cf92 created 2017-10-02 | ||
| 25 | + #### Generating tokens | ||
| 32 | 26 | ||
| 33 | - ``` | ||
| 27 | + When generating tokens, you will be prompted you for your password and, if you have two-factor authentication enabled, an otp. | ||
| 34 | 28 | ||
| 35 | - * `npm token create [--read-only] [--cidr=<cidr-ranges>]`: | ||
| 36 | - Create a new authentication token. | ||
| 37 | - 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. | ||
| 38 | - This will prompt you for your password, and, if you have two-factor authentication enabled, an otp. | ||
| 29 | + Please refer to the [docs website](https://docs.npmjs.com/creating-and-viewing-access-tokens) for more information on generating tokens for CI/CD. | ||
| 39 | 30 | ||
| 40 | - Currently, the cli cannot generate automation tokens. | ||
| 41 | - Please refer to the [docs website](https://docs.npmjs.com/creating-and-viewing-access-tokens) for more information on generating automation tokens. | ||
| 31 | + #### Revoking tokens | ||
| 42 | 32 | ||
| 43 | - ``` | ||
| 44 | - Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d | ||
| 45 | - ``` | ||
| 33 | + 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. | ||
| 46 | 34 | ||
| 47 | - * `npm token revoke <token|id>`: | ||
| 48 | - Immediately removes an authentication token from the registry. | ||
| 49 | - You will no longer be able to use it. | ||
| 50 | - 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`. | ||
| 51 | - This will NOT accept the truncated token found in the normal `npm token list` output. | ||
| 35 | + A revoked token will immediately be removed from the registry and you will no longer be able to use it. | ||
| 52 | 36 | ||
| 53 | 37 | ### Configuration | |
| 54 | 38 | ||
@@ -88,8 +72,7 @@ expiration. | |||
| 88 | 72 | * Type: null or String (can be set multiple times) | |
| 89 | 73 | ||
| 90 | 74 | When creating a Granular Access Token with `npm token create`, this limits | |
| 91 | - the token access to specific packages. Provide a comma-separated list of | ||
| 92 | - package names. | ||
| 75 | + the token access to specific packages. | ||
| 93 | 76 | ||
| 94 | 77 | ||
| 95 | 78 | ||
@@ -109,8 +92,8 @@ token access to all packages instead of limiting to specific packages. | |||
| 109 | 92 | * Type: null or String (can be set multiple times) | |
| 110 | 93 | ||
| 111 | 94 | When creating a Granular Access Token with `npm token create`, this limits | |
| 112 | - the token access to specific scopes. Provide a comma-separated list of scope | ||
| 113 | - names (with or without @ prefix). | ||
| 95 | + the token access to specific scopes. Provide a scope name (with or without @ | ||
| 96 | + prefix). | ||
| 114 | 97 | ||
| 115 | 98 | ||
| 116 | 99 | ||
@@ -120,8 +103,7 @@ names (with or without @ prefix). | |||
| 120 | 103 | * Type: null or String (can be set multiple times) | |
| 121 | 104 | ||
| 122 | 105 | When creating a Granular Access Token with `npm token create`, this limits | |
| 123 | - the token access to specific organizations. Provide a comma-separated list | ||
| 124 | - of organization names. | ||
| 106 | + the token access to specific organizations. | ||
| 125 | 107 | ||
| 126 | 108 | ||
| 127 | 109 | ||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -180,10 +180,14 @@ The `newversion` argument should be a valid semver string, a valid second argume | |||
| 180 | 180 | In the second case, the existing version will be incremented by 1 in the specified field. | |
| 181 | 181 | `from-git` will try to read the latest git tag, and use that as the new npm version. | |
| 182 | 182 | ||
| 183 | + **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`. | ||
| 184 | + | ||
| 183 | 185 | If run in a git repo, it will also create a version commit and tag. | |
| 184 | 186 | 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`. | |
| 185 | 187 | It will fail if the working directory is not clean, unless the `-f` or `--force` flag is set. | |
| 186 | 188 | ||
| 189 | + **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. | ||
| 190 | + | ||
| 187 | 191 | If supplied with `-m` or [`--message` config](/using-npm/config#message) option, npm will use it as a commit message when creating a version commit. | |
| 188 | 192 | If the `message` config contains `%s` then that will be replaced with the resulting version number. | |
| 189 | 193 | For example: | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -74,6 +74,22 @@ If the field value you are querying for is a property of an object, you should r | |||
| 74 | 74 | npm view express time'[4.8.0]' | |
| 75 | 75 | ``` | |
| 76 | 76 | ||
| 77 | + Note: When accessing object properties that contain special characters or numeric keys, you need to use quotes around the key name. | ||
| 78 | + For example, to get the publish time of a specific version: | ||
| 79 | + | ||
| 80 | + ```bash | ||
| 81 | + npm view express "time[4.17.1]" | ||
| 82 | + ``` | ||
| 83 | + | ||
| 84 | + Without quotes, the shell may interpret the square brackets as glob patterns, causing the command to fail. | ||
| 85 | + You can also access the time field for a specific version by specifying the version in the package descriptor: | ||
| 86 | + | ||
| 87 | + ```bash | ||
| 88 | + npm view express@4.17.1 time | ||
| 89 | + ``` | ||
| 90 | + | ||
| 91 | + This will return all version-time pairs, but the context will be for that specific version. | ||
| 92 | + | ||
| 77 | 93 | Multiple fields may be specified, and will be printed one after another. | |
| 78 | 94 | For example, to get all the contributor names and email addresses, you can do this: | |
| 79 | 95 | ||
@@ -102,6 +118,56 @@ To show the `connect` package version history, you can do this: | |||
| 102 | 118 | npm view connect versions | |
| 103 | 119 | ``` | |
| 104 | 120 | ||
| 121 | + ### Field Access Patterns | ||
| 122 | + | ||
| 123 | + 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. | ||
| 124 | + | ||
| 125 | + #### Nested Object Fields | ||
| 126 | + | ||
| 127 | + Use dot notation to access nested object fields: | ||
| 128 | + | ||
| 129 | + ```bash | ||
| 130 | + # Access nested properties | ||
| 131 | + npm view npm repository.url | ||
| 132 | + npm view express bugs.url | ||
| 133 | + ``` | ||
| 134 | + | ||
| 135 | + #### Array Element Access | ||
| 136 | + | ||
| 137 | + For arrays, use numeric indices in square brackets to access specific elements: | ||
| 138 | + | ||
| 139 | + ```bash | ||
| 140 | + # Get the first contributor's email | ||
| 141 | + npm view express contributors[0].email | ||
| 142 | + | ||
| 143 | + # Get the second maintainer's name | ||
| 144 | + npm view express maintainers[1].name | ||
| 145 | + ``` | ||
| 146 | + | ||
| 147 | + #### Object Property Access | ||
| 148 | + | ||
| 149 | + For object properties (like accessing specific versions in the `time` field), use bracket notation with the property name in quotes: | ||
| 150 | + | ||
| 151 | + ```bash | ||
| 152 | + # Get publish time for a specific version | ||
| 153 | + npm view express "time[4.17.1]" | ||
| 154 | + | ||
| 155 | + # Get dist-tags | ||
| 156 | + npm view express "dist-tags.latest" | ||
| 157 | + ``` | ||
| 158 | + | ||
| 159 | + #### Extracting Fields from Arrays | ||
| 160 | + | ||
| 161 | + Request a non-numeric field on an array to get all values from objects in the list: | ||
| 162 | + | ||
| 163 | + ```bash | ||
| 164 | + # Get all contributor emails | ||
| 165 | + npm view express contributors.email | ||
| 166 | + | ||
| 167 | + # Get all contributor names | ||
| 168 | + npm view express contributors.name | ||
| 169 | + ``` | ||
| 170 | + | ||
| 105 | 171 | ### Configuration | |
| 106 | 172 | ||
| 107 | 173 | #### `json` | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -14,7 +14,7 @@ Note: This command is unaware of workspaces. | |||
| 14 | 14 | ||
| 15 | 15 | ### Version | |
| 16 | 16 | ||
| 17 | - 11.6.4 | ||
| 17 | + 11.7.0 | ||
| 18 | 18 | ||
| 19 | 19 | ### Description | |
| 20 | 20 | ||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -17,6 +17,8 @@ npx --package=foo -c '<cmd> [args...]' | |||
| 17 | 17 | ||
| 18 | 18 | 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`. | |
| 19 | 19 | ||
| 20 | + 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). | ||
| 21 | + | ||
| 20 | 22 | 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. | |
| 21 | 23 | The `--package` option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available. | |
| 22 | 24 | ||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -335,6 +335,12 @@ For most modules, it makes the most sense to have a main script and often not mu | |||
| 335 | 335 | ||
| 336 | 336 | If `main` is not set, it defaults to `index.js` in the package's root folder. | |
| 337 | 337 | ||
| 338 | + ### type | ||
| 339 | + | ||
| 340 | + The `type` field defines how Node.js should interpret `.js` files in your package. This field is not used by npm. | ||
| 341 | + | ||
| 342 | + See the [Node.js documentation on the type field](https://nodejs.org/api/packages.html#type) for more information. | ||
| 343 | + | ||
| 338 | 344 | ### browser | |
| 339 | 345 | ||
| 340 | 346 | If your module is meant to be used client-side the browser field should be used instead of the main field. | |
@@ -502,6 +508,19 @@ For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same | |||
| 502 | 508 | } | |
| 503 | 509 | ``` | |
| 504 | 510 | ||
| 511 | + **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: | ||
| 512 | + | ||
| 513 | + ```json | ||
| 514 | + { | ||
| 515 | + "repository": { | ||
| 516 | + "type": "git", | ||
| 517 | + "url": "git+https://github.com/npm/example.git" | ||
| 518 | + } | ||
| 519 | + } | ||
| 520 | + ``` | ||
| 521 | + | ||
| 522 | + You can run `npm pkg fix` to automatically convert shorthand formats to the normalized object format. | ||
| 523 | + | ||
| 505 | 524 | 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: | |
| 506 | 525 | ||
| 507 | 526 | ```json | |
@@ -521,6 +540,20 @@ The key is the lifecycle event, and the value is the command to run at that poin | |||
| 521 | 540 | ||
| 522 | 541 | See [`scripts`](/using-npm/scripts) to find out more about writing package scripts. | |
| 523 | 542 | ||
| 543 | + ### gypfile | ||
| 544 | + | ||
| 545 | + 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. | ||
| 546 | + | ||
| 547 | + To prevent npm from automatically building your module with node-gyp, set `gypfile` to `false`: | ||
| 548 | + | ||
| 549 | + ```json | ||
| 550 | + { | ||
| 551 | + "gypfile": false | ||
| 552 | + } | ||
| 553 | + ``` | ||
| 554 | + | ||
| 555 | + 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. | ||
| 556 | + | ||
| 524 | 557 | ### config | |
| 525 | 558 | ||
| 526 | 559 | A "config" object can be used to set configuration parameters used in package scripts that persist across upgrades. | |
@@ -926,6 +959,53 @@ To make this limitation easier to deal with, overrides may also be defined as a | |||
| 926 | 959 | } | |
| 927 | 960 | ``` | |
| 928 | 961 | ||
| 962 | + #### Replacing a dependency with a fork | ||
| 963 | + | ||
| 964 | + You can replace a package with a different package or fork using several methods: | ||
| 965 | + | ||
| 966 | + **Using the `npm:` prefix to replace with a different package name:** | ||
| 967 | + | ||
| 968 | + ```json | ||
| 969 | + { | ||
| 970 | + "overrides": { | ||
| 971 | + "package-name": "npm:@scope/forked-package@1.0.0" | ||
| 972 | + } | ||
| 973 | + } | ||
| 974 | + ``` | ||
| 975 | + | ||
| 976 | + **Using a GitHub repository (supports branches, tags, or commit hashes):** | ||
| 977 | + | ||
| 978 | + ```json | ||
| 979 | + { | ||
| 980 | + "overrides": { | ||
| 981 | + "package-name": "github:username/repo#branch-name" | ||
| 982 | + } | ||
| 983 | + } | ||
| 984 | + ``` | ||
| 985 | + | ||
| 986 | + **Using a local file path:** | ||
| 987 | + | ||
| 988 | + ```json | ||
| 989 | + { | ||
| 990 | + "overrides": { | ||
| 991 | + "package-name": "file:../local-fork" | ||
| 992 | + } | ||
| 993 | + } | ||
| 994 | + ``` | ||
| 995 | + | ||
| 996 | + These replacement methods work for both top-level overrides and nested overrides. | ||
| 997 | + For example, to replace a transitive dependency with a fork: | ||
| 998 | + | ||
| 999 | + ```json | ||
| 1000 | + { | ||
| 1001 | + "overrides": { | ||
| 1002 | + "parent-package": { | ||
| 1003 | + "vulnerable-dep": "github:username/patched-fork#v2.0.1" | ||
| 1004 | + } | ||
| 1005 | + } | ||
| 1006 | + } | ||
| 1007 | + ``` | ||
| 1008 | + | ||
| 929 | 1009 | ### engines | |
| 930 | 1010 | ||
| 931 | 1011 | You can specify the version of node that your stuff works on: | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -136,6 +136,7 @@ npm v7 ignores this section entirely if a `packages` section is present, but doe | |||
| 136 | 136 | Dependency objects have the following fields: | |
| 137 | 137 | ||
| 138 | 138 | * version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it. | |
| 139 | + Note that for peer dependencies that are not installed, or optional dependencies that are not installed, this field may be omitted. | ||
| 139 | 140 | ||
| 140 | 141 | * bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes. | |
| 141 | 142 | * registry sources: This is a version number. | |
@@ -149,6 +150,8 @@ Dependency objects have the following fields: | |||
| 149 | 150 | * local link sources: This is the file URL of the link. | |
| 150 | 151 | (eg `file:libs/our-module`) | |
| 151 | 152 | ||
| 153 | + **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. | ||
| 154 | + | ||
| 152 | 155 | * 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. | |
| 153 | 156 | For git dependencies, this is the commit sha. | |
| 154 | 157 | ||
| Back | FazBrowse Home | New Git URL |
0 commit comments