diff --git a/docs/lib/content/commands/npm-access.md b/docs/lib/content/commands/npm-access.md index 907b94e7edea2..5ad8ccca246cd 100644 --- a/docs/lib/content/commands/npm-access.md +++ b/docs/lib/content/commands/npm-access.md @@ -12,9 +12,7 @@ description: Set access level on published packages Used to set access controls on private packages. -For all of the subcommands, `npm access` will perform actions on the packages -in the current working directory if no package name is passed to the -subcommand. +For all of the subcommands, `npm access` will perform actions on the packages in the current working directory if no package name is passed to the subcommand. * grant / revoke: Add or remove the ability of users and teams to have read-only or read-write @@ -22,14 +20,11 @@ subcommand. ### Details -`npm access` always operates directly on the current registry, configurable -from the command line using `--registry=`. +`npm access` always operates directly on the current registry, configurable from the command line using `--registry=`. Unscoped packages are *always public*. -Scoped packages *default to restricted*, but you can either publish them as -public using `npm publish --access=public`, or set their access as public using -`npm access set status=public` after the initial publish. +Scoped packages *default to restricted*, but you can either publish them as public using `npm publish --access=public`, or set their access as public using `npm access set status=public` after the initial publish. You must have privileges to set the access of a package: @@ -38,11 +33,9 @@ You must have privileges to set the access of a package: * You have been given read-write privileges for a package, either as a member of a team or directly as an owner. -If you have two-factor authentication enabled then you'll be prompted to provide a second factor, or may use the `--otp=...` option to specify it on -the command line. +If you have two-factor authentication enabled then you'll be prompted to provide a second factor, or may use the `--otp=...` option to specify it on the command line. -If your account is not paid, then attempts to publish scoped packages will -fail with an HTTP 402 status code (logically enough), unless you use +If your account is not paid, then attempts to publish scoped packages will fail with an HTTP 402 status code (logically enough), unless you use `--access=public`. Management of teams and team memberships is done with the `npm team` command. diff --git a/docs/lib/content/commands/npm-adduser.md b/docs/lib/content/commands/npm-adduser.md index 63626bec2cf56..a7f0d0a1a9fbb 100644 --- a/docs/lib/content/commands/npm-adduser.md +++ b/docs/lib/content/commands/npm-adduser.md @@ -10,14 +10,13 @@ description: Add a registry user account ### Description -Create a new user in the specified registry, and save the credentials to -the `.npmrc` file. If no registry is specified, the default registry -will be used (see [`registry`](/using-npm/registry)). +Create a new user in the specified registry, and save the credentials to the `.npmrc` file. +If no registry is specified, the default registry will be used (see [`registry`](/using-npm/registry)). -When you run `npm adduser`, the CLI automatically generates a legacy token of `publish` type. For more information, see [About legacy tokens](/about-access-tokens#about-legacy-tokens). +When you run `npm adduser`, the CLI automatically generates a legacy token of `publish` type. +For more information, see [About legacy tokens](/about-access-tokens#about-legacy-tokens). -When using `legacy` for your `auth-type`, the username, password, and -email are read in from prompts. +When using `legacy` for your `auth-type`, the username, password, and email are read in from prompts. ### Configuration diff --git a/docs/lib/content/commands/npm-audit.md b/docs/lib/content/commands/npm-audit.md index 361cfbe4bbf61..c51c722ef86f7 100644 --- a/docs/lib/content/commands/npm-audit.md +++ b/docs/lib/content/commands/npm-audit.md @@ -10,32 +10,23 @@ description: Run a security audit ### Description -The audit command submits a description of the dependencies configured in -your project to your default registry and asks for a report of known -vulnerabilities. If any vulnerabilities are found, then the impact and -appropriate remediation will be calculated. If the `fix` argument is -provided, then remediations will be applied to the package tree. +The audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities. +If any vulnerabilities are found, then the impact and appropriate remediation will be calculated. +If the `fix` argument is provided, then remediations will be applied to the package tree. The command will exit with a 0 exit code if no vulnerabilities were found. -Note that some vulnerabilities cannot be fixed automatically and will -require manual intervention or review. Also note that since `npm audit -fix` runs a full-fledged `npm install` under the hood, all configs that -apply to the installer will also apply to `npm install` -- so things like -`npm audit fix --package-lock-only` will work as expected. +Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review. +Also note that since `npm audit fix` runs a full-fledged `npm install` under the hood, all configs that apply to the installer will also apply to `npm install` -- so things like `npm audit fix --package-lock-only` will work as expected. -By default, the audit command will exit with a non-zero code if any -vulnerability is found. It may be useful in CI environments to include the -`--audit-level` parameter to specify the minimum vulnerability level that -will cause the command to fail. This option does not filter the report -output, it simply changes the command's failure threshold. +By default, the audit command will exit with a non-zero code if any vulnerability is found. +It may be useful in CI environments to include the `--audit-level` parameter to specify the minimum vulnerability level that will cause the command to fail. +This option does not filter the report output, it simply changes the command's failure threshold. ### Package lock -By default npm requires a package-lock or shrinkwrap in order to run the -audit. You can bypass the package lock with `--no-package-lock` but be -aware the results may be different with every run, since npm will -re-build the dependency tree each time. +By default npm requires a package-lock or shrinkwrap in order to run the audit. +You can bypass the package lock with `--no-package-lock` but be aware the results may be different with every run, since npm will re-build the dependency tree each time. ### Audit Signatures @@ -47,12 +38,9 @@ Registry signatures can be verified using the following `audit` command: $ npm audit signatures ``` -The `audit signatures` command will also verify the provenance attestations of -downloaded packages. Because provenance attestations are such a new feature, -security features may be added to (or changed in) the attestation format over -time. To ensure that you're always able to verify attestation signatures check -that you're running the latest version of the npm CLI. Please note this often -means updating npm beyond the version that ships with Node.js. +The `audit signatures` command will also verify the provenance attestations of downloaded packages. +Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time. +To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js. The npm CLI supports registry signatures and signing keys provided by any registry if the following conventions are followed: @@ -98,42 +86,29 @@ See this [example key's response from the public npm registry](https://registry. ### Audit Endpoints -There are two audit endpoints that npm may use to fetch vulnerability -information: the `Bulk Advisory` endpoint and the `Quick Audit` endpoint. +There are two audit endpoints that npm may use to fetch vulnerability information: the `Bulk Advisory` endpoint and the `Quick Audit` endpoint. #### Bulk Advisory Endpoint -As of version 7, npm uses the much faster `Bulk Advisory` endpoint to -optimize the speed of calculating audit results. +As of version 7, npm uses the much faster `Bulk Advisory` endpoint to optimize the speed of calculating audit results. -npm will generate a JSON payload with the name and list of versions of each -package in the tree, and POST it to the default configured registry at -the path `/-/npm/v1/security/advisories/bulk`. +npm will generate a JSON payload with the name and list of versions of each package in the tree, and POST it to the default configured registry at the path `/-/npm/v1/security/advisories/bulk`. -Any packages in the tree that do not have a `version` field in their -package.json file will be ignored. If any `--omit` options are specified -(either via the [`--omit` config](/using-npm/config#omit), or one of the -shorthands such as `--production`, `--only=dev`, and so on), then packages will -be omitted from the submitted payload as appropriate. +Any packages in the tree that do not have a `version` field in their package.json file will be ignored. +If any `--omit` options are specified (either via the [`--omit` config](/using-npm/config#omit), or one of the shorthands such as `--production`, `--only=dev`, and so on), then packages will be omitted from the submitted payload as appropriate. -If the registry responds with an error, or with an invalid response, then -npm will attempt to load advisory data from the `Quick Audit` endpoint. +If the registry responds with an error, or with an invalid response, then npm will attempt to load advisory data from the `Quick Audit` endpoint. -The expected result will contain a set of advisory objects for each -dependency that matches the advisory range. Each advisory object contains -a `name`, `url`, `id`, `severity`, `vulnerable_versions`, and `title`. +The expected result will contain a set of advisory objects for each dependency that matches the advisory range. +Each advisory object contains a `name`, `url`, `id`, `severity`, `vulnerable_versions`, and `title`. -npm then uses these advisory objects to calculate vulnerabilities and -meta-vulnerabilities of the dependencies within the tree. +npm then uses these advisory objects to calculate vulnerabilities and meta-vulnerabilities of the dependencies within the tree. #### Quick Audit Endpoint -If the `Bulk Advisory` endpoint returns an error, or invalid data, npm will -attempt to load advisory data from the `Quick Audit` endpoint, which is -considerably slower in most cases. +If the `Bulk Advisory` endpoint returns an error, or invalid data, npm will attempt to load advisory data from the `Quick Audit` endpoint, which is considerably slower in most cases. -The full package tree as found in `package-lock.json` is submitted, along -with the following pieces of additional metadata: +The full package tree as found in `package-lock.json` is submitted, along with the following pieces of additional metadata: * `npm_version` * `node_version` @@ -146,64 +121,42 @@ Omitted dependency types are skipped when generating the report. #### Scrubbing -Out of an abundance of caution, npm versions 5 and 6 would "scrub" any -packages from the submitted report if their name contained a `/` character, -so as to avoid leaking the names of potentially private packages or git -URLs. +Out of an abundance of caution, npm versions 5 and 6 would "scrub" any packages from the submitted report if their name contained a `/` character, so as to avoid leaking the names of potentially private packages or git URLs. -However, in practice, this resulted in audits often failing to properly -detect meta-vulnerabilities, because the tree would appear to be invalid -due to missing dependencies, and prevented the detection of vulnerabilities -in package trees that used git dependencies or private modules. +However, in practice, this resulted in audits often failing to properly detect meta-vulnerabilities, because the tree would appear to be invalid due to missing dependencies, and prevented the detection of vulnerabilities in package trees that used git dependencies or private modules. This scrubbing has been removed from npm as of version 7. #### Calculating Meta-Vulnerabilities and Remediations -npm uses the -[`@npmcli/metavuln-calculator`](http://npm.im/@npmcli/metavuln-calculator) -module to turn a set of security advisories into a set of "vulnerability" -objects. A "meta-vulnerability" is a dependency that is vulnerable by -virtue of dependence on vulnerable versions of a vulnerable package. +npm uses the [`@npmcli/metavuln-calculator`](http://npm.im/@npmcli/metavuln-calculator) module to turn a set of security advisories into a set of "vulnerability" objects. +A "meta-vulnerability" is a dependency that is vulnerable by virtue of dependence on vulnerable versions of a vulnerable package. -For example, if the package `foo` is vulnerable in the range `>=1.0.2 -<2.0.0`, and the package `bar` depends on `foo@^1.1.0`, then that version -of `bar` can only be installed by installing a vulnerable version of `foo`. +For example, if the package `foo` is vulnerable in the range `>=1.0.2 <2.0.0`, and the package `bar` depends on `foo@^1.1.0`, then that version of `bar` can only be installed by installing a vulnerable version of `foo`. In this case, `bar` is a "metavulnerability". -Once metavulnerabilities for a given package are calculated, they are -cached in the `~/.npm` folder and only re-evaluated if the advisory range -changes, or a new version of the package is published (in which case, the -new version is checked for metavulnerable status as well). +Once metavulnerabilities for a given package are calculated, they are cached in the `~/.npm` folder and only re-evaluated if the advisory range changes, or a new version of the package is published (in which case, the new version is checked for metavulnerable status as well). -If the chain of metavulnerabilities extends all the way to the root -project, and it cannot be updated without changing its dependency ranges, -then `npm audit fix` will require the `--force` option to apply the -remediation. If remediations do not require changes to the dependency -ranges, then all vulnerable packages will be updated to a version that does -not have an advisory or metavulnerability posted against it. +If the chain of metavulnerabilities extends all the way to the root project, and it cannot be updated without changing its dependency ranges, then `npm audit fix` will require the `--force` option to apply the remediation. +If remediations do not require changes to the dependency ranges, then all vulnerable packages will be updated to a version that does not have an advisory or metavulnerability posted against it. ### Exit Code -The `npm audit` command will exit with a 0 exit code if no vulnerabilities -were found. The `npm audit fix` command will exit with 0 exit code if no -vulnerabilities are found _or_ if the remediation is able to successfully -fix all vulnerabilities. +The `npm audit` command will exit with a 0 exit code if no vulnerabilities were found. +The `npm audit fix` command will exit with 0 exit code if no vulnerabilities are found _or_ if the remediation is able to successfully fix all vulnerabilities. If vulnerabilities were found the exit code will depend on the [`audit-level` config](/using-npm/config#audit-level). ### Examples -Scan your project for vulnerabilities and automatically install any compatible -updates to vulnerable dependencies: +Scan your project for vulnerabilities and automatically install any compatible updates to vulnerable dependencies: ```bash $ npm audit fix ``` -Run `audit fix` without modifying `node_modules`, but still updating the -pkglock: +Run `audit fix` without modifying `node_modules`, but still updating the pkglock: ```bash $ npm audit fix --package-lock-only @@ -215,22 +168,19 @@ Skip updating `devDependencies`: $ npm audit fix --only=prod ``` -Have `audit fix` install SemVer-major updates to toplevel dependencies, not -just SemVer-compatible ones: +Have `audit fix` install SemVer-major updates to toplevel dependencies, not just SemVer-compatible ones: ```bash $ npm audit fix --force ``` -Do a dry run to get an idea of what `audit fix` will do, and _also_ output -install information in JSON format: +Do a dry run to get an idea of what `audit fix` will do, and _also_ output install information in JSON format: ```bash $ npm audit fix --dry-run --json ``` -Scan your project for vulnerabilities and just show the details, without -fixing anything: +Scan your project for vulnerabilities and just show the details, without fixing anything: ```bash $ npm audit diff --git a/docs/lib/content/commands/npm-bugs.md b/docs/lib/content/commands/npm-bugs.md index 4cf90510d7124..e68361084196d 100644 --- a/docs/lib/content/commands/npm-bugs.md +++ b/docs/lib/content/commands/npm-bugs.md @@ -10,11 +10,8 @@ description: Report bugs for a package in a web browser ### Description -This command tries to guess at the likely location of a package's bug -tracker URL or the `mailto` URL of the support email, and then tries to -open it using the [`--browser` config](/using-npm/config#browser) param. If no -package name is provided, it will search for a `package.json` in the current -folder and use the `name` property. +This command tries to guess at the likely location of a package's bug tracker URL or the `mailto` URL of the support email, and then tries to open it using the [`--browser` config](/using-npm/config#browser) param. +If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property. ### Configuration diff --git a/docs/lib/content/commands/npm-cache.md b/docs/lib/content/commands/npm-cache.md index f41282969d09e..55835d23e1c92 100644 --- a/docs/lib/content/commands/npm-cache.md +++ b/docs/lib/content/commands/npm-cache.md @@ -16,10 +16,12 @@ Also used to view info about entries in the `npm exec` (aka `npx`) cache folder. #### `npm cache` * add: - Add the specified packages to the local cache. This command is primarily intended to be used internally by npm, but it can provide a way to add data to the local installation cache explicitly. + Add the specified packages to the local cache. + This command is primarily intended to be used internally by npm, but it can provide a way to add data to the local installation cache explicitly. * clean: - Delete a single entry or all entries out of the cache folder. Note that this is typically unnecessary, as npm's cache is self-healing and resistant to data corruption issues. + Delete a single entry or all entries out of the cache folder. + Note that this is typically unnecessary, as npm's cache is self-healing and resistant to data corruption issues. * ls: List given entries or all entries in the local cache. @@ -40,20 +42,26 @@ Also used to view info about entries in the `npm exec` (aka `npx`) cache folder. ### Details -npm stores cache data in an opaque directory within the configured `cache`, named `_cacache`. This directory is a [`cacache`](http://npm.im/cacache)-based content-addressable cache that stores all http request data as well as other package-related data. This directory is primarily accessed through `pacote`, the library responsible for all package fetching as of npm@5. +npm stores cache data in an opaque directory within the configured `cache`, named `_cacache`. +This directory is a [`cacache`](http://npm.im/cacache)-based content-addressable cache that stores all http request data as well as other package-related data. +This directory is primarily accessed through `pacote`, the library responsible for all package fetching as of npm@5. -All data that passes through the cache is fully verified for integrity on both insertion and extraction. Cache corruption will either trigger an error, or signal to `pacote` that the data must be refetched, which it will do automatically. For this reason, it should never be necessary to clear the cache for any reason other than reclaiming disk space, thus why `clean` now requires `--force` to run. +All data that passes through the cache is fully verified for integrity on both insertion and extraction. +Cache corruption will either trigger an error, or signal to `pacote` that the data must be refetched, which it will do automatically. +For this reason, it should never be necessary to clear the cache for any reason other than reclaiming disk space, thus why `clean` now requires `--force` to run. -There is currently no method exposed through npm to inspect or directly manage the contents of this cache. In order to access it, `cacache` must be used directly. +There is currently no method exposed through npm to inspect or directly manage the contents of this cache. +In order to access it, `cacache` must be used directly. npm will not remove data by itself: the cache will grow as new packages are installed. ### A note about the cache's design -The npm cache is strictly a cache: it should not be relied upon as a persistent and reliable data store for package data. npm makes no guarantee that a previously-cached piece of data will be available later, and will automatically delete corrupted contents. The primary guarantee that the cache makes is that, if it does return data, that data will be exactly the data that was inserted. +The npm cache is strictly a cache: it should not be relied upon as a persistent and reliable data store for package data. +npm makes no guarantee that a previously-cached piece of data will be available later, and will automatically delete corrupted contents. +The primary guarantee that the cache makes is that, if it does return data, that data will be exactly the data that was inserted. -To run an offline verification of existing cache contents, use `npm cache -verify`. +To run an offline verification of existing cache contents, use `npm cache verify`. ### Configuration diff --git a/docs/lib/content/commands/npm-ci.md b/docs/lib/content/commands/npm-ci.md index d26691c3c29c6..4bddcb402862b 100644 --- a/docs/lib/content/commands/npm-ci.md +++ b/docs/lib/content/commands/npm-ci.md @@ -10,10 +10,8 @@ description: Clean install a project ### Description -This command is similar to [`npm install`](/commands/npm-install), except -it's meant to be used in automated environments such as test platforms, -continuous integration, and deployment -- or any situation where you want -to make sure you're doing a clean install of your dependencies. +This command is similar to [`npm install`](/commands/npm-install), except it's meant to be used in automated environments such as test platforms, +continuous integration, and deployment -- or any situation where you want to make sure you're doing a clean install of your dependencies. The main differences between using `npm install` and `npm ci` are: @@ -30,9 +28,8 @@ The main differences between using `npm install` and `npm ci` are: NOTE: If you create your `package-lock.json` file by running `npm install` with flags that can affect the shape of your dependency tree, such as -`--legacy-peer-deps` or `--install-links`, you _must_ provide the same -flags to `npm ci` or you are likely to encounter errors. An easy way to do -this is to run, for example, +`--legacy-peer-deps` or `--install-links`, you _must_ provide the same flags to `npm ci` or you are likely to encounter errors. +An easy way to do this is to run, for example, `npm config set legacy-peer-deps=true --location=project` and commit the `.npmrc` file to your repo. diff --git a/docs/lib/content/commands/npm-completion.md b/docs/lib/content/commands/npm-completion.md index dcc25997fa585..3019ce1fd4c5c 100644 --- a/docs/lib/content/commands/npm-completion.md +++ b/docs/lib/content/commands/npm-completion.md @@ -12,24 +12,19 @@ description: Tab Completion for npm Enables tab-completion in all npm commands. -The synopsis above -loads the completions into your current shell. Adding it to -your ~/.bashrc or ~/.zshrc will make the completions available -everywhere: +The synopsis above loads the completions into your current shell. +Adding it to your ~/.bashrc or ~/.zshrc will make the completions available everywhere: ```bash npm completion >> ~/.bashrc npm completion >> ~/.zshrc ``` -You may of course also pipe the output of `npm completion` to a file -such as `/usr/local/etc/bash_completion.d/npm` or +You may of course also pipe the output of `npm completion` to a file such as `/usr/local/etc/bash_completion.d/npm` or `/etc/bash_completion.d/npm` if you have a system that will read that file for you. -When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the -environment, `npm completion` acts in "plumbing mode", and outputs -completions based on the arguments. +When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the environment, `npm completion` acts in "plumbing mode", and outputs completions based on the arguments. ### See Also diff --git a/docs/lib/content/commands/npm-config.md b/docs/lib/content/commands/npm-config.md index c3a67f6349eb3..965eeeb01e628 100644 --- a/docs/lib/content/commands/npm-config.md +++ b/docs/lib/content/commands/npm-config.md @@ -10,17 +10,13 @@ description: Manage the npm configuration files ### Description -npm gets its config settings from the command line, environment -variables, `npmrc` files, and in some cases, the `package.json` file. +npm gets its config settings from the command line, environment variables, `npmrc` files, and in some cases, the `package.json` file. -See [npmrc](/configuring-npm/npmrc) for more information about the npmrc -files. +See [npmrc](/configuring-npm/npmrc) for more information about the npmrc files. -See [config](/using-npm/config) for a more thorough explanation of the -mechanisms involved, and a full list of config options available. +See [config](/using-npm/config) for a more thorough explanation of the mechanisms involved, and a full list of config options available. -The `npm config` command can be used to update and edit the contents -of the user and global npmrc files. +The `npm config` command can be used to update and edit the contents of the user and global npmrc files. ### Sub-commands @@ -33,13 +29,12 @@ npm config set key=value [key=value...] npm set key=value [key=value...] ``` -Sets each of the config keys to the value provided. Modifies the user configuration -file unless [`location`](/commands/npm-config#location) is passed. +Sets each of the config keys to the value provided. +Modifies the user configuration file unless [`location`](/commands/npm-config#location) is passed. If value is omitted, the key will be removed from your config file entirely. -Note: for backwards compatibility, `npm config set key value` is supported -as an alias for `npm config set key=value`. +Note: for backwards compatibility, `npm config set key value` is supported as an alias for `npm config set key=value`. #### get @@ -50,11 +45,9 @@ npm get [key ...] Echo the config value(s) to stdout. -If multiple keys are provided, then the values will be prefixed with the -key names. +If multiple keys are provided, then the values will be prefixed with the key names. -If no keys are provided, then this command behaves the same as `npm config -list`. +If no keys are provided, then this command behaves the same as `npm config list`. #### list @@ -62,7 +55,9 @@ list`. npm config list ``` -Show all the config settings. Use `-l` to also show defaults. Use `--json` +Show all the config settings. +Use `-l` to also show defaults. +Use `--json` to show the settings in json format. #### delete @@ -79,8 +74,8 @@ Deletes the specified keys from all configuration files. npm config edit ``` -Opens the config file in an editor. Use the `--global` flag to edit the -global config. +Opens the config file in an editor. +Use the `--global` flag to edit the global config. #### fix @@ -88,9 +83,9 @@ global config. npm config fix ``` -Attempts to repair invalid configuration items. Usually this means -attaching authentication config (i.e. `_auth`, `_authToken`) to the -configured `registry`. +Attempts to repair invalid configuration items. +Usually this means attaching authentication config (i.e. +`_auth`, `_authToken`) to the configured `registry`. ### Configuration diff --git a/docs/lib/content/commands/npm-dedupe.md b/docs/lib/content/commands/npm-dedupe.md index 877a130c1431c..21ea4b64bcd03 100644 --- a/docs/lib/content/commands/npm-dedupe.md +++ b/docs/lib/content/commands/npm-dedupe.md @@ -10,9 +10,7 @@ description: Reduce duplication in the package tree ### Description -Searches the local package tree and attempts to simplify the overall -structure by moving dependencies further up the tree, where they can -be more effectively shared by multiple dependent packages. +Searches the local package tree and attempts to simplify the overall structure by moving dependencies further up the tree, where they can be more effectively shared by multiple dependent packages. For example, consider this dependency graph: @@ -33,9 +31,7 @@ a `-- c@1.0.10 ``` -Because of the hierarchical nature of node's module lookup, b and d -will both get their dependency met by the single c package at the root -level of the tree. +Because of the hierarchical nature of node's module lookup, b and d will both get their dependency met by the single c package at the root level of the tree. In some cases, you may have a dependency graph like this: @@ -47,29 +43,22 @@ a `-- c@1.9.9 ``` -During the installation process, the `c@1.0.3` dependency for `b` was -placed in the root of the tree. Though `d`'s dependency on `c@1.x` could -have been satisfied by `c@1.0.3`, the newer `c@1.9.0` dependency was used, -because npm favors updates by default, even when doing so causes -duplication. +During the installation process, the `c@1.0.3` dependency for `b` was placed in the root of the tree. +Though `d`'s dependency on `c@1.x` could have been satisfied by `c@1.0.3`, the newer `c@1.9.0` dependency was used, +because npm favors updates by default, even when doing so causes duplication. -Running `npm dedupe` will cause npm to note the duplication and -re-evaluate, deleting the nested `c` module, because the one in the root is -sufficient. +Running `npm dedupe` will cause npm to note the duplication and re-evaluate, deleting the nested `c` module, because the one in the root is sufficient. -To prefer deduplication over novelty during the installation process, run -`npm install --prefer-dedupe` or `npm config set prefer-dedupe true`. +To prefer deduplication over novelty during the installation process, run `npm install --prefer-dedupe` or `npm config set prefer-dedupe true`. -Arguments are ignored. Dedupe always acts on the entire tree. +Arguments are ignored. +Dedupe always acts on the entire tree. -Note that this operation transforms the dependency tree, but will never -result in new modules being installed. +Note that this operation transforms the dependency tree, but will never result in new modules being installed. Using `npm find-dupes` will run the command in `--dry-run` mode. -Note: `npm dedupe` will never update the semver values of direct -dependencies in your project `package.json`, if you want to update -values in `package.json` you can run: `npm update --save` instead. +Note: `npm dedupe` will never update the semver values of direct dependencies in your project `package.json`, if you want to update values in `package.json` you can run: `npm update --save` instead. ### Configuration diff --git a/docs/lib/content/commands/npm-deprecate.md b/docs/lib/content/commands/npm-deprecate.md index dbe785f05588c..143b892637cee 100644 --- a/docs/lib/content/commands/npm-deprecate.md +++ b/docs/lib/content/commands/npm-deprecate.md @@ -10,18 +10,17 @@ description: Deprecate a version of a package ### Description -This command will update the npm registry entry for a package, providing a -deprecation warning to all who attempt to install it. +This command will update the npm registry entry for a package, providing a deprecation warning to all who attempt to install it. -It works on [version ranges](https://semver.npmjs.com/) as well as specific -versions, so you can do something like this: +It works on [version ranges](https://semver.npmjs.com/) as well as specific versions, so you can do something like this: ```bash npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3" ``` SemVer ranges passed to this command are interpreted such that they *do* -include prerelease versions. For example: +include prerelease versions. +For example: ```bash npm deprecate my-thing@1.x "1.x is no longer supported" @@ -29,12 +28,12 @@ npm deprecate my-thing@1.x "1.x is no longer supported" In this case, a version `my-thing@1.0.0-beta.0` will also be deprecated. -You must be the package owner to deprecate something. See the `owner` and -`adduser` help topics. +You must be the package owner to deprecate something. +See the `owner` and `adduser` help topics. To un-deprecate a package, specify an empty string (`""`) for the `message` -argument. Note that you must use double quotes with no space between them to -format an empty string. +argument. +Note that you must use double quotes with no space between them to format an empty string. ### Configuration diff --git a/docs/lib/content/commands/npm-diff.md b/docs/lib/content/commands/npm-diff.md index 5a10841a9c2d8..fa6580e2a1f7d 100644 --- a/docs/lib/content/commands/npm-diff.md +++ b/docs/lib/content/commands/npm-diff.md @@ -10,22 +10,16 @@ description: The registry diff command ### Description -Similar to its `git diff` counterpart, this command will print diff patches -of files for packages published to the npm registry. +Similar to its `git diff` counterpart, this command will print diff patches of files for packages published to the npm registry. * `npm diff --diff= --diff=` - Compares two package versions using their registry specifiers, e.g: - `npm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0`. It's also possible to - compare across forks of any package, - e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0`. + Compares two package versions using their registry specifiers, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0`. + It's also possible to compare across forks of any package, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0`. - Any valid spec can be used, so that it's also possible to compare - directories or git repositories, - e.g: `npm diff --diff=pkg@latest --diff=./packages/pkg` + Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: `npm diff --diff=pkg@latest --diff=./packages/pkg` - Here's an example comparing two different versions of a package named - `abbrev` from the registry: + Here's an example comparing two different versions of a package named `abbrev` from the registry: ```bash npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1 @@ -48,39 +42,24 @@ of files for packages published to the npm registry. "main": "abbrev.js", ``` - Given the flexible nature of npm specs, you can also target local - directories or git repos just like when using `npm install`: + Given the flexible nature of npm specs, you can also target local directories or git repos just like when using `npm install`: ```bash npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path ``` - In the example above we can compare the contents from the package installed - from the git repo at `github.com/npm/libnpmdiff` with the contents of the - `./local-path` that contains a valid package, such as a modified copy of - the original. + In the example above we can compare the contents from the package installed from the git repo at `github.com/npm/libnpmdiff` with the contents of the `./local-path` that contains a valid package, such as a modified copy of the original. * `npm diff` (in a package directory, no arguments): - If the package is published to the registry, `npm diff` will fetch the - tarball version tagged as `latest` (this value can be configured using the - `tag` option) and proceed to compare the contents of files present in that - tarball, with the current files in your local file system. + If the package is published to the registry, `npm diff` will fetch the tarball version tagged as `latest` (this value can be configured using the `tag` option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system. - This workflow provides a handy way for package authors to see what - package-tracked files have been changed in comparison with the latest - published version of that package. + This workflow provides a handy way for package authors to see what package-tracked files have been changed in comparison with the latest published version of that package. * `npm diff --diff=` (in a package directory): - When using a single package name (with no version or tag specifier) as an - argument, `npm diff` will work in a similar way to - [`npm-outdated`](npm-outdated) and reach for the registry to figure out - what current published version of the package named `` - will satisfy its dependent declared semver-range. Once that specific - version is known `npm diff` will print diff patches comparing the - current version of `` found in the local file system with - that specific version returned by the registry. + When using a single package name (with no version or tag specifier) as an argument, `npm diff` will work in a similar way to [`npm-outdated`](npm-outdated) and reach for the registry to figure out what current published version of the package named `` will satisfy its dependent declared semver-range. + Once that specific version is known `npm diff` will print diff patches comparing the current version of `` found in the local file system with that specific version returned by the registry. Given a package named `abbrev` that is currently installed: @@ -88,19 +67,13 @@ of files for packages published to the npm registry. npm diff --diff=abbrev ``` - That will request from the registry its most up to date version and - will print a diff output comparing the currently installed version to this - newer one if the version numbers are not the same. + That will request from the registry its most up to date version and will print a diff output comparing the currently installed version to this newer one if the version numbers are not the same. * `npm diff --diff=` (in a package directory): - Similar to using only a single package name, it's also possible to declare - a full registry specifier version if you wish to compare the local version - of an installed package with the specific version/tag/semver-range provided - in ``. + Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in ``. - An example: assuming `pkg@1.0.0` is installed in the current `node_modules` - folder, running: + An example: assuming `pkg@1.0.0` is installed in the current `node_modules` folder, running: ```bash npm diff --diff=pkg@2.0.0 @@ -111,39 +84,29 @@ of files for packages published to the npm registry. * `npm diff --diff= [--diff=]` (in a package directory): - Using `npm diff` along with semver-valid version numbers is a shorthand - to compare different versions of the current package. + Using `npm diff` along with semver-valid version numbers is a shorthand to compare different versions of the current package. - It needs to be run from a package directory, such that for a package named - `pkg` running `npm diff --diff=1.0.0 --diff=1.0.1` is the same as running - `npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1`. + It needs to be run from a package directory, such that for a package named `pkg` running `npm diff --diff=1.0.0 --diff=1.0.1` is the same as running `npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1`. - If only a single argument `` is provided, then the current local - file system is going to be compared against that version. + If only a single argument `` is provided, then the current local file system is going to be compared against that version. - Here's an example comparing two specific versions (published to the - configured registry) of the current project directory: + Here's an example comparing two specific versions (published to the configured registry) of the current project directory: ```bash npm diff --diff=1.0.0 --diff=1.1.0 ``` -Note that tag names are not valid `--diff` argument values, if you wish to -compare to a published tag, you must use the `pkg@tagname` syntax. +Note that tag names are not valid `--diff` argument values, if you wish to compare to a published tag, you must use the `pkg@tagname` syntax. #### Filtering files -It's possible to also specify positional arguments using file names or globs -pattern matching in order to limit the result of diff patches to only a subset -of files for a given package, e.g: +It's possible to also specify positional arguments using file names or globs pattern matching in order to limit the result of diff patches to only a subset of files for a given package, e.g: ```bash npm diff --diff=pkg@2 ./lib/ CHANGELOG.md ``` -In the example above the diff output is only going to print contents of files -located within the folder `./lib/` and changed lines of code within the -`CHANGELOG.md` file. +In the example above the diff output is only going to print contents of files located within the folder `./lib/` and changed lines of code within the `CHANGELOG.md` file. ### Configuration diff --git a/docs/lib/content/commands/npm-dist-tag.md b/docs/lib/content/commands/npm-dist-tag.md index 40484c63edad5..fdd6e048d066c 100644 --- a/docs/lib/content/commands/npm-dist-tag.md +++ b/docs/lib/content/commands/npm-dist-tag.md @@ -12,22 +12,16 @@ description: Modify package distribution tags Add, remove, and enumerate distribution tags on a package: -* add: Tags the specified version of the package with the specified tag, - or the [`--tag` config](/using-npm/config#tag) if not specified. If you have - two-factor authentication on auth-and-writes then you’ll need to include a - one-time password on the command line with - `--otp `, or go through a second factor flow based on your `authtype`. +* add: Tags the specified version of the package with the specified tag, or the [`--tag` config](/using-npm/config#tag) if not specified. + If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp `, or go through a second factor flow based on your `authtype`. -* rm: Clear a tag that is no longer in use from the package. If you have - two-factor authentication on auth-and-writes then you’ll need to include - a one-time password on the command line with `--otp `, - or go through a second factor flow based on your `authtype` +* rm: Clear a tag that is no longer in use from the package. + If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp `, or go through a second factor flow based on your `authtype` -* ls: Show all of the dist-tags for a package, defaulting to the package in - the current prefix. This is the default action if none is specified. +* ls: Show all of the dist-tags for a package, defaulting to the package in the current prefix. + This is the default action if none is specified. -A tag can be used when installing packages as a reference to a version instead -of using a specific version number: +A tag can be used when installing packages as a reference to a version instead of using a specific version number: ```bash npm install @ @@ -39,28 +33,22 @@ When installing dependencies, a preferred tagged version may be specified: npm install --tag ``` -(This also applies to any other commands that resolve and install -dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.) +(This also applies to any other commands that resolve and install dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.) -Publishing a package sets the `latest` tag to the published version unless the -`--tag` option is used. For example, `npm publish --tag=beta`. +Publishing a package sets the `latest` tag to the published version unless the `--tag` option is used. +For example, `npm publish --tag=beta`. -By default, `npm install ` (without any `@` or `@` -specifier) installs the `latest` tag. +By default, `npm install ` (without any `@` or `@` specifier) installs the `latest` tag. ### Purpose Tags can be used to provide an alias instead of version numbers. -For example, a project might choose to have multiple streams of development -and use a different tag for each stream, e.g., `stable`, `beta`, `dev`, +For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., `stable`, `beta`, `dev`, `canary`. -By default, the `latest` tag is used by npm to identify the current version -of a package, and `npm install ` (without any `@` or `@` -specifier) installs the `latest` tag. Typically, projects only use the -`latest` tag for stable release versions, and use other tags for unstable -versions such as prereleases. +By default, the `latest` tag is used by npm to identify the current version of a package, and `npm install ` (without any `@` or `@` specifier) installs the `latest` tag. +Typically, projects only use the `latest` tag for stable release versions, and use other tags for unstable versions such as prereleases. The `next` tag is used by some projects to identify the upcoming version. @@ -68,19 +56,15 @@ Other than `latest`, no tag has any special significance to npm itself. ### Caveats -This command used to be known as `npm tag`, which only created new tags, -and so had a different syntax. +This command used to be known as `npm tag`, which only created new tags, and so had a different syntax. -Tags must share a namespace with version numbers, because they are -specified in the same slot: `npm install @` vs -`npm install @`. +Tags must share a namespace with version numbers, because they are specified in the same slot: `npm install @` vs `npm install @`. -Tags that can be interpreted as valid semver ranges will be rejected. For -example, `v1.4` cannot be used as a tag, because it is interpreted by -semver as `>=1.4.0 <1.5.0`. See . +Tags that can be interpreted as valid semver ranges will be rejected. +For example, `v1.4` cannot be used as a tag, because it is interpreted by semver as `>=1.4.0 <1.5.0`. +See . -The simplest way to avoid semver problems with tags is to use tags that do -not begin with a number or the letter `v`. +The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter `v`. ### Configuration diff --git a/docs/lib/content/commands/npm-docs.md b/docs/lib/content/commands/npm-docs.md index 140d23dfa7e86..af42437093e22 100644 --- a/docs/lib/content/commands/npm-docs.md +++ b/docs/lib/content/commands/npm-docs.md @@ -10,11 +10,10 @@ description: Open documentation for a package in a web browser ### Description -This command tries to guess at the likely location of a package's -documentation URL, and then tries to open it using the -[`--browser` config](/using-npm/config#browser) param. You can pass multiple -package names at once. If no package name is provided, it will search for a -`package.json` in the current folder and use the `name` property. +This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the +[`--browser` config](/using-npm/config#browser) param. +You can pass multiple package names at once. +If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property. ### Configuration diff --git a/docs/lib/content/commands/npm-doctor.md b/docs/lib/content/commands/npm-doctor.md index b5c8126b272c0..c7f09a818c2bb 100644 --- a/docs/lib/content/commands/npm-doctor.md +++ b/docs/lib/content/commands/npm-doctor.md @@ -10,9 +10,8 @@ description: Check the health of your npm environment ### Description -`npm doctor` runs a set of checks to ensure that your npm installation has -what it needs to manage your JavaScript packages. npm is mostly a -standalone tool, but it does have some basic requirements that must be met: +`npm doctor` runs a set of checks to ensure that your npm installation has what it needs to manage your JavaScript packages. +npm is mostly a standalone tool, but it does have some basic requirements that must be met: + Node.js and git must be executable by npm. + The primary npm registry, `registry.npmjs.com`, or another service that @@ -21,68 +20,57 @@ standalone tool, but it does have some basic requirements that must be met: globally), exist and can be written by the current user. + The npm cache exists, and the package tarballs within it aren't corrupt. -Without all of these working properly, npm may not work properly. Many -issues are often attributable to things that are outside npm's code base, +Without all of these working properly, npm may not work properly. +Many issues are often attributable to things that are outside npm's code base, so `npm doctor` confirms that the npm installation is in a good state. -Also, in addition to this, there are also very many issue reports due to -using old versions of npm. Since npm is constantly improving, running -`npm@latest` is better than an old version. +Also, in addition to this, there are also very many issue reports due to using old versions of npm. +Since npm is constantly improving, running `npm@latest` is better than an old version. -`npm doctor` verifies the following items in your environment, and if -there are any recommended changes, it will display them. By default npm -runs all of these checks. You can limit what checks are ran by -specifying them as extra arguments. +`npm doctor` verifies the following items in your environment, and if there are any recommended changes, it will display them. +By default npm runs all of these checks. +You can limit what checks are ran by specifying them as extra arguments. #### `Connecting to the registry` By default, npm installs from the primary npm registry, -`registry.npmjs.org`. `npm doctor` hits a special connection testing -endpoint within the registry. This can also be checked with `npm ping`. -If this check fails, you may be using a proxy that needs to be -configured, or may need to talk to your IT staff to get access over +`registry.npmjs.org`. +`npm doctor` hits a special connection testing endpoint within the registry. +This can also be checked with `npm ping`. +If this check fails, you may be using a proxy that needs to be configured, or may need to talk to your IT staff to get access over HTTPS to `registry.npmjs.org`. -This check is done against whichever registry you've configured (you can -see what that is by running `npm config get registry`), and if you're using -a private registry that doesn't support the `/whoami` endpoint supported by -the primary registry, this check may fail. +This check is done against whichever registry you've configured (you can see what that is by running `npm config get registry`), and if you're using +a private registry that doesn't support the `/whoami` endpoint supported by the primary registry, this check may fail. #### `Checking npm version` -While Node.js may come bundled with a particular version of npm, it's the -policy of the CLI team that we recommend all users run `npm@latest` if they -can. As the CLI is maintained by a small team of contributors, there are -only resources for a single line of development, so npm's own long-term -support releases typically only receive critical security and regression -fixes. The team believes that the latest tested version of npm is almost -always likely to be the most functional and defect-free version of npm. +While Node.js may come bundled with a particular version of npm, it's the policy of the CLI team that we recommend all users run `npm@latest` if they can. +As the CLI is maintained by a small team of contributors, there are only resources for a single line of development, so npm's own long-term support releases typically only receive critical security and regression fixes. +The team believes that the latest tested version of npm is almost always likely to be the most functional and defect-free version of npm. #### `Checking node version` -For most users, in most circumstances, the best version of Node will be the -latest long-term support (LTS) release. Those of you who want access to new -ECMAscript features or bleeding-edge changes to Node's standard library may -be running a newer version, and some may be required to run an older -version of Node because of enterprise change control policies. That's OK! +For most users, in most circumstances, the best version of Node will be the latest long-term support (LTS) release. +Those of you who want access to new +ECMAscript features or bleeding-edge changes to Node's standard library may be running a newer version, and some may be required to run an older version of Node because of enterprise change control policies. +That's OK! But in general, the npm team recommends that most users run Node.js LTS. #### `Checking configured npm registry` -You may be installing from private package registries for your project or -company. That's great! Others may be following tutorials or StackOverflow -questions in an effort to troubleshoot problems you may be having. -Sometimes, this may entail changing the registry you're pointing at. This -part of `npm doctor` just lets you, and maybe whoever's helping you with -support, know that you're not using the default registry. +You may be installing from private package registries for your project or company. +That's great! Others may be following tutorials or StackOverflow questions in an effort to troubleshoot problems you may be having. +Sometimes, this may entail changing the registry you're pointing at. +This part of `npm doctor` just lets you, and maybe whoever's helping you with support, know that you're not using the default registry. #### `Checking for git executable in PATH` While it's documented in the README, it may not be obvious that npm needs -Git installed to do many of the things that it does. Also, in some cases -– especially on Windows – you may have Git set up in such a way that it's -not accessible via your `PATH` so that npm can find it. This check ensures -that Git is available. +Git installed to do many of the things that it does. +Also, in some cases +– especially on Windows – you may have Git set up in such a way that it's not accessible via your `PATH` so that npm can find it. +This check ensures that Git is available. #### Permissions checks @@ -93,13 +81,9 @@ that Git is available. #### Validate the checksums of cached packages -When an npm package is published, the publishing process generates a -checksum that npm uses at install time to verify that the package didn't -get corrupted in transit. `npm doctor` uses these checksums to validate the -package tarballs in your local cache (you can see where that cache is -located with `npm config get cache`). In the event that there are corrupt -packages in your cache, you should probably run `npm cache clean -f` and -reset the cache. +When an npm package is published, the publishing process generates a checksum that npm uses at install time to verify that the package didn't get corrupted in transit. +`npm doctor` uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with `npm config get cache`). +In the event that there are corrupt packages in your cache, you should probably run `npm cache clean -f` and reset the cache. ### Configuration diff --git a/docs/lib/content/commands/npm-edit.md b/docs/lib/content/commands/npm-edit.md index e00c4a345dc17..8072bd99b2c06 100644 --- a/docs/lib/content/commands/npm-edit.md +++ b/docs/lib/content/commands/npm-edit.md @@ -10,16 +10,12 @@ description: Edit an installed package ### Description -Selects a dependency in the current project and opens the package folder in -the default editor (or whatever you've configured as the npm `editor` +Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm `editor` config -- see [`npm-config`](npm-config).) -After it has been edited, the package is rebuilt so as to pick up any -changes in compiled packages. +After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages. -For instance, you can do `npm install connect` to install connect -into your package, and then `npm edit connect` to make a few -changes to your locally installed copy. +For instance, you can do `npm install connect` to install connect into your package, and then `npm edit connect` to make a few changes to your locally installed copy. ### Configuration diff --git a/docs/lib/content/commands/npm-exec.md b/docs/lib/content/commands/npm-exec.md index ad11efb9a1807..9869afe6ea41c 100644 --- a/docs/lib/content/commands/npm-exec.md +++ b/docs/lib/content/commands/npm-exec.md @@ -10,58 +10,34 @@ description: Run a command from a local or remote npm package ### Description -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`. - -Run without positional arguments or `--call`, this allows you to -interactively run commands in the same sort of shell environment that -`package.json` scripts are run. Interactive mode is not supported in CI -environments when standard input is a TTY, to prevent hangs. - -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. - -If any requested packages are not present in the local project -dependencies, then a prompt is printed, which can be suppressed by -providing either `--yes` or `--no`. When standard input is not a TTY or a -CI environment is detected, `--yes` is assumed. The requested packages are -installed to a folder in the npm cache, which is added to the `PATH` -environment variable in the executed process. - -Package names provided without a specifier will be matched with whatever -version exists in the local project. Package names with a specifier will -only be considered a match if they have the exact same name and version as -the local dependency. - -If no `-c` or `--call` option is provided, then the positional arguments -are used to generate the command string. If no `--package` options -are provided, then npm will attempt to determine the executable name from -the package specifier provided as the first positional argument according -to the following heuristic: - -- If the package has a single entry in its `bin` field in `package.json`, - or if all entries are aliases of the same command, then that command - will be used. -- If the package has multiple `bin` entries, and one of them matches the - unscoped portion of the `name` field, then that command will be used. -- If this does not result in exactly one option (either because there are - no bin entries, or none of them match the `name` of the package), then - `npm exec` exits with an error. - -To run a binary _other than_ the named binary, specify one or more -`--package` options, which will prevent npm from inferring the package from -the first command argument. +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`. + +Run without positional arguments or `--call`, this allows you to interactively run commands in the same sort of shell environment that `package.json` scripts are run. +Interactive mode is not supported in CI environments when standard input is a TTY, to prevent hangs. + +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. + +If any requested packages are not present in the local project dependencies, then a prompt is printed, which can be suppressed by providing either `--yes` or `--no`. +When standard input is not a TTY or a CI environment is detected, `--yes` is assumed. +The requested packages are installed to a folder in the npm cache, which is added to the `PATH` environment variable in the executed process. + +Package names provided without a specifier will be matched with whatever version exists in the local project. +Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency. + +If no `-c` or `--call` option is provided, then the positional arguments are used to generate the command string. +If no `--package` options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic: + +- If the package has a single entry in its `bin` field in `package.json`, or if all entries are aliases of the same command, then that command will be used. +- If the package has multiple `bin` entries, and one of them matches the unscoped portion of the `name` field, then that command will be used. +- If this does not result in exactly one option (either because there are no bin entries, or none of them match the `name` of the package), then `npm exec` exits with an error. + +To run a binary _other than_ the named binary, specify one or more `--package` options, which will prevent npm from inferring the package from the first command argument. ### `npx` vs `npm exec` -When run via the `npx` binary, all flags and options *must* be set prior to -any positional arguments. When run via `npm exec`, a double-hyphen `--` -flag can be used to suppress npm's parsing of switches and options that -should be sent to the executed command. +When run via the `npx` binary, all flags and options *must* be set prior to any positional arguments. +When run via `npm exec`, a double-hyphen `--` flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command. For example: @@ -69,34 +45,29 @@ For example: $ npx foo@latest bar --package=@npmcli/foo ``` -In this case, npm will resolve the `foo` package name, and run the -following command: +In this case, npm will resolve the `foo` package name, and run the following command: ``` $ foo bar --package=@npmcli/foo ``` -Since the `--package` option comes _after_ the positional arguments, it is -treated as an argument to the executed command. +Since the `--package` option comes _after_ the positional arguments, it is treated as an argument to the executed command. -In contrast, due to npm's argument parsing logic, running this command is -different: +In contrast, due to npm's argument parsing logic, running this command is different: ``` $ npm exec foo@latest bar --package=@npmcli/foo ``` -In this case, npm will parse the `--package` option first, resolving the -`@npmcli/foo` package. Then, it will execute the following command in that -context: +In this case, npm will parse the `--package` option first, resolving the `@npmcli/foo` package. +Then, it will execute the following command in that context: ``` $ foo@latest bar ``` -The double-hyphen character is recommended to explicitly tell npm to stop -parsing command line options and switches. The following command would -thus be equivalent to the `npx` command above: +The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches. +The following command would thus be equivalent to the `npx` command above: ``` $ npm exec -- foo@latest bar --package=@npmcli/foo @@ -108,16 +79,14 @@ $ npm exec -- foo@latest bar --package=@npmcli/foo ### Examples -Run the version of `tap` in the local dependencies, with the provided -arguments: +Run the version of `tap` in the local dependencies, with the provided arguments: ``` $ npm exec -- tap --bail test/foo.js $ npx tap --bail test/foo.js ``` -Run a command _other than_ the command whose name matches the package name -by specifying a `--package` option: +Run a command _other than_ the command whose name matches the package name by specifying a `--package` option: ``` $ npm exec --package=foo -- bar --bar-argument @@ -134,13 +103,8 @@ $ npx -c 'eslint && say "hooray, lint passed"' ### Workspaces support -You may use the [`workspace`](/using-npm/config#workspace) or -[`workspaces`](/using-npm/config#workspaces) configs in order to run an -arbitrary command from an npm package (either one installed locally, or fetched -remotely) in the context of the specified workspaces. -If no positional argument or `--call` option is provided, it will open an -interactive subshell in the context of each of these configured workspaces one -at a time. +You may use the [`workspace`](/using-npm/config#workspace) or [`workspaces`](/using-npm/config#workspaces) configs in order to run an arbitrary command from an npm package (either one installed locally, or fetched remotely) in the context of the specified workspaces. +If no positional argument or `--call` option is provided, it will open an interactive subshell in the context of each of these configured workspaces one at a time. Given a project with configured workspaces, e.g: @@ -156,8 +120,8 @@ Given a project with configured workspaces, e.g: `-- package.json ``` -Assuming the workspace configuration is properly set up at the root level -`package.json` file. e.g: +Assuming the workspace configuration is properly set up at the root level `package.json` file. +e.g: ``` { @@ -165,10 +129,7 @@ Assuming the workspace configuration is properly set up at the root level } ``` -You can execute an arbitrary command from a package in the context of each of -the configured workspaces when using the -[`workspaces` config options](/using-npm/config#workspace), in this example -we're using **eslint** to lint any js file found within each workspace folder: +You can execute an arbitrary command from a package in the context of each of the configured workspaces when using the [`workspaces` config options](/using-npm/config#workspace), in this example we're using **eslint** to lint any js file found within each workspace folder: ``` npm exec --ws -- eslint ./*.js @@ -176,17 +137,14 @@ npm exec --ws -- eslint ./*.js #### Filtering workspaces -It's also possible to execute a command in a single workspace using the -`workspace` config along with a name or directory path: +It's also possible to execute a command in a single workspace using the `workspace` config along with a name or directory path: ``` npm exec --workspace=a -- eslint ./*.js ``` -The `workspace` config can also be specified multiple times in order to run a -specific script in the context of multiple workspaces. When defining values for -the `workspace` config in the command line, it also possible to use `-w` as a -shorthand, e.g: +The `workspace` config can also be specified multiple times in order to run a specific script in the context of multiple workspaces. +When defining values for the `workspace` config in the command line, it also possible to use `-w` as a shorthand, e.g: ``` npm exec -w a -w b -- eslint ./*.js @@ -197,69 +155,60 @@ This last command will run the `eslint` command in both `./packages/a` and ### Compatibility with Older npx Versions -The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx` -package deprecated at that time. `npx` uses the `npm exec` -command instead of a separate argument parser and install process, with -some affordances to maintain backwards compatibility with the arguments it -accepted in previous versions. +The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx` package deprecated at that time. +`npx` uses the `npm exec` command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions. This resulted in some shifts in its functionality: - Any `npm` config value may be provided. - To prevent security and user-experience problems from mistyping package - names, `npx` prompts before installing anything. Suppress this - prompt with the `-y` or `--yes` option. + names, `npx` prompts before installing anything. + Suppress this prompt with the `-y` or `--yes` option. - The `--no-install` option is deprecated, and will be converted to `--no`. - Shell fallback functionality is removed, as it is not advisable. -- The `-p` argument is a shorthand for `--parseable` in npm, but shorthand - for `--package` in npx. This is maintained, but only for the `npx` - executable. -- The `--ignore-existing` option is removed. Locally installed bins are - always present in the executed process `PATH`. -- The `--npm` option is removed. `npx` will always use the `npm` it ships - with. +- The `-p` argument is a shorthand for `--parseable` in npm, but shorthand for `--package` in npx. + This is maintained, but only for the `npx` executable. +- The `--ignore-existing` option is removed. + Locally installed bins are always present in the executed process `PATH`. +- The `--npm` option is removed. + `npx` will always use the `npm` it ships with. - The `--node-arg` and `-n` options are removed. - The `--always-spawn` option is redundant, and thus removed. -- The `--shell` option is replaced with `--script-shell`, but maintained - in the `npx` executable for backwards compatibility. +- The `--shell` option is replaced with `--script-shell`, but maintained in the `npx` executable for backwards compatibility. ### A note on caching -The npm cli utilizes its internal package cache when using the package -name specified. You can use the following to change how and when the -cli uses this cache. See [`npm cache`](/commands/npm-cache) for more on -how the cache works. +The npm cli utilizes its internal package cache when using the package name specified. +You can use the following to change how and when the cli uses this cache. +See [`npm cache`](/commands/npm-cache) for more on how the cache works. #### prefer-online -Forces staleness checks for packages, making the cli look for updates -immediately even if the package is already in the cache. +Forces staleness checks for packages, making the cli look for updates immediately even if the package is already in the cache. #### prefer-offline -Bypasses staleness checks for packages. Missing data will still be -requested from the server. To force full offline mode, use `offline`. +Bypasses staleness checks for packages. +Missing data will still be requested from the server. +To force full offline mode, use `offline`. #### offline -Forces full offline mode. Any packages not locally cached will result in -an error. +Forces full offline mode. +Any packages not locally cached will result in an error. #### workspace * Default: * Type: 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. +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 to selecting all of the - nested workspaces) +* Path to a parent workspace directory (will result to selecting all of the nested workspaces) This value is not exported to the environment for child processes. @@ -269,8 +218,7 @@ This value is not exported to the environment for child processes. * Type: Boolean * Default: `false` -Run scripts in the context of all configured workspaces for the current -project. +Run scripts in the context of all configured workspaces for the current project. ### See Also diff --git a/docs/lib/content/commands/npm-explain.md b/docs/lib/content/commands/npm-explain.md index 8de05c92f8b2c..577a6521919ae 100644 --- a/docs/lib/content/commands/npm-explain.md +++ b/docs/lib/content/commands/npm-explain.md @@ -10,11 +10,9 @@ description: Explain installed packages ### Description -This command will print the chain of dependencies causing a given package -to be installed in the current project. +This command will print the chain of dependencies causing a given package to be installed in the current project. -If one or more package specs are provided, then only packages matching -one of the specifiers will have their relationships explained. +If one or more package specs are provided, then only packages matching one of the specifiers will have their relationships explained. The package spec can also refer to a folder within `./node_modules` @@ -34,10 +32,8 @@ node_modules/tacks/node_modules/glob dev tacks@"^1.3.0" from the root project ``` -To explain just the package residing at a specific folder, pass that as the -argument to the command. This can be useful when trying to figure out -exactly why a given dependency is being duplicated to satisfy conflicting -version requirements within the project. +To explain just the package residing at a specific folder, pass that as the argument to the command. +This can be useful when trying to figure out exactly why a given dependency is being duplicated to satisfy conflicting version requirements within the project. ```bash $ npm explain node_modules/nyc/node_modules/find-up diff --git a/docs/lib/content/commands/npm-explore.md b/docs/lib/content/commands/npm-explore.md index c277e4bec7bd6..f92d46629bcee 100644 --- a/docs/lib/content/commands/npm-explore.md +++ b/docs/lib/content/commands/npm-explore.md @@ -12,18 +12,15 @@ description: Browse an installed package Spawn a subshell in the directory of the installed package specified. -If a command is specified, then it is run in the subshell, which then -immediately terminates. +If a command is specified, then it is run in the subshell, which then immediately terminates. -This is particularly handy in the case of git submodules in the -`node_modules` folder: +This is particularly handy in the case of git submodules in the `node_modules` folder: ```bash npm explore some-dependency -- git pull origin master ``` -Note that the package is *not* automatically rebuilt afterwards, so be -sure to use `npm rebuild ` if you make any changes. +Note that the package is *not* automatically rebuilt afterwards, so be sure to use `npm rebuild ` if you make any changes. ### Configuration diff --git a/docs/lib/content/commands/npm-find-dupes.md b/docs/lib/content/commands/npm-find-dupes.md index 1e0e8df3d21d0..ea77122aa3a47 100644 --- a/docs/lib/content/commands/npm-find-dupes.md +++ b/docs/lib/content/commands/npm-find-dupes.md @@ -10,8 +10,7 @@ description: Find duplication in the package tree ### Description -Runs `npm dedupe` in `--dry-run` mode, making npm only output the -duplications, without actually changing the package tree. +Runs `npm dedupe` in `--dry-run` mode, making npm only output the duplications, without actually changing the package tree. ### Configuration diff --git a/docs/lib/content/commands/npm-fund.md b/docs/lib/content/commands/npm-fund.md index f200aafc3e828..779b1441e62d4 100644 --- a/docs/lib/content/commands/npm-fund.md +++ b/docs/lib/content/commands/npm-fund.md @@ -10,31 +10,25 @@ description: Retrieve funding information ### Description -This command retrieves information on how to fund the dependencies of a -given project. If no package name is provided, it will list all -dependencies that are looking for funding in a tree structure, listing -the type of funding and the url to visit. If a package name is provided -then it tries to open its funding url using the -[`--browser` config](/using-npm/config#browser) param; if there are multiple -funding sources for the package, the user will be instructed to pass the +This command retrieves information on how to fund the dependencies of a given project. +If no package name is provided, it will list all dependencies that are looking for funding in a tree structure, listing the type of funding and the url to visit. +If a package name is provided then it tries to open its funding url using the +[`--browser` config](/using-npm/config#browser) param; if there are multiple funding sources for the package, the user will be instructed to pass the `--which` option to disambiguate. -The list will avoid duplicated entries and will stack all packages that -share the same url as a single entry. Thus, the list does not have the -same shape of the output from `npm ls`. +The list will avoid duplicated entries and will stack all packages that share the same url as a single entry. +Thus, the list does not have the same shape of the output from `npm ls`. #### Example ### Workspaces support -It's possible to filter the results to only include a single workspace -and its dependencies using the +It's possible to filter the results to only include a single workspace and its dependencies using the [`workspace` config](/using-npm/config#workspace) option. #### Example: -Here's an example running `npm fund` in a project with a configured -workspace `a`: +Here's an example running `npm fund` in a project with a configured workspace `a`: ```bash $ npm fund @@ -49,8 +43,7 @@ test-workspaces-fund@1.0.0 `-- bar@2.0.0 ``` -And here is an example of the expected result when filtering only by a -specific workspace `a` in the same project: +And here is an example of the expected result when filtering only by a specific workspace `a` in the same project: ```bash $ npm fund -w a diff --git a/docs/lib/content/commands/npm-help-search.md b/docs/lib/content/commands/npm-help-search.md index e419f03fdd438..095cb6878f337 100644 --- a/docs/lib/content/commands/npm-help-search.md +++ b/docs/lib/content/commands/npm-help-search.md @@ -10,14 +10,12 @@ description: Search npm help documentation ### Description -This command will search the npm markdown documentation files for the terms -provided, and then list the results, sorted by relevance. +This command will search the npm markdown documentation files for the terms provided, and then list the results, sorted by relevance. If only one result is found, then it will show that help topic. -If the argument to `npm help` is not a known help topic, then it will call -`help-search`. It is rarely if ever necessary to call this command -directly. +If the argument to `npm help` is not a known help topic, then it will call `help-search`. +It is rarely if ever necessary to call this command directly. ### Configuration diff --git a/docs/lib/content/commands/npm-help.md b/docs/lib/content/commands/npm-help.md index cefb917991113..a12a832243cee 100644 --- a/docs/lib/content/commands/npm-help.md +++ b/docs/lib/content/commands/npm-help.md @@ -12,10 +12,8 @@ description: Get help on npm If supplied a topic, then show the appropriate documentation page. -If the topic does not exist, or if multiple terms are provided, then npm -will run the `help-search` command to find a match. Note that, if -`help-search` finds a single subject, then it will run `help` on that -topic, so unique matches are equivalent to specifying a topic name. +If the topic does not exist, or if multiple terms are provided, then npm will run the `help-search` command to find a match. +Note that, if `help-search` finds a single subject, then it will run `help` on that topic, so unique matches are equivalent to specifying a topic name. ### Configuration diff --git a/docs/lib/content/commands/npm-init.md b/docs/lib/content/commands/npm-init.md index 4f364d01f84c0..20c6700557c53 100644 --- a/docs/lib/content/commands/npm-init.md +++ b/docs/lib/content/commands/npm-init.md @@ -10,16 +10,12 @@ description: Create a package.json file ### Description -`npm init ` can be used to set up a new or existing npm -package. +`npm init ` can be used to set up a new or existing npm package. `initializer` in this case is an npm package named `create-`, -which will be installed by [`npm-exec`](/commands/npm-exec), and then have its -main bin executed -- presumably creating or updating `package.json` and -running any other initialization-related operations. +which will be installed by [`npm-exec`](/commands/npm-exec), and then have its main bin executed -- presumably creating or updating `package.json` and running any other initialization-related operations. -The init command is transformed to a corresponding `npm exec` operation as -follows: +The init command is transformed to a corresponding `npm exec` operation as follows: * `npm init foo` -> `npm exec create-foo` * `npm init @usr/foo` -> `npm exec @usr/create-foo` @@ -27,18 +23,15 @@ follows: * `npm init @usr@2.0.0` -> `npm exec @usr/create@2.0.0` * `npm init @usr/foo@2.0.0` -> `npm exec @usr/create-foo@2.0.0` -If the initializer is omitted (by just calling `npm init`), init will fall -back to legacy init behavior. It will ask you a bunch of questions, and -then write a package.json for you. It will attempt to make reasonable -guesses based on existing fields, dependencies, and options selected. It is -strictly additive, so it will keep any fields and values that were already -set. You can also use `-y`/`--yes` to skip the questionnaire altogether. If -you pass `--scope`, it will create a scoped package. +If the initializer is omitted (by just calling `npm init`), init will fall back to legacy init behavior. +It will ask you a bunch of questions, and then write a package.json for you. +It will attempt to make reasonable guesses based on existing fields, dependencies, and options selected. +It is strictly additive, so it will keep any fields and values that were already set. +You can also use `-y`/`--yes` to skip the questionnaire altogether. +If you pass `--scope`, it will create a scoped package. -*Note:* if a user already has the `create-` package -globally installed, that will be what `npm init` uses. If you want npm -to use the latest version, or another specific version you must specify -it: +*Note:* if a user already has the `create-` package globally installed, that will be what `npm init` uses. +If you want npm to use the latest version, or another specific version you must specify it: * `npm init foo@latest` # fetches and runs the latest `create-foo` from the registry @@ -46,11 +39,9 @@ it: #### Forwarding additional options -Any additional options will be passed directly to the command, so `npm init -foo -- --hello` will map to `npm exec -- create-foo --hello`. +Any additional options will be passed directly to the command, so `npm init foo -- --hello` will map to `npm exec -- create-foo --hello`. -To better illustrate how options are forwarded, here's a more evolved -example showing options passed to both the **npm cli** and a create package, +To better illustrate how options are forwarded, here's a more evolved example showing options passed to both the **npm cli** and a create package, both following commands are equivalent: - `npm init foo -y --registry= -- --hello -a` @@ -94,11 +85,8 @@ $ npm init --init-private -y ### Workspaces support -It's possible to create a new workspace within your project by using the -`workspace` config option. When using `npm init -w ` the cli will -create the folders and boilerplate expected while also adding a reference -to your project `package.json` `"workspaces": []` property in order to make -sure that new generated **workspace** is properly set up as such. +It's possible to create a new workspace within your project by using the `workspace` config option. +When using `npm init -w ` the cli will create the folders and boilerplate expected while also adding a reference to your project `package.json` `"workspaces": []` property in order to make sure that new generated **workspace** is properly set up as such. Given a project with no workspaces, e.g: @@ -113,8 +101,7 @@ You may generate a new workspace using the legacy init: $ npm init -w packages/a ``` -That will generate a new folder and `package.json` file, while also updating -your top-level `package.json` to add the reference to this new workspace: +That will generate a new folder and `package.json` file, while also updating your top-level `package.json` to add the reference to this new workspace: ``` . @@ -126,21 +113,15 @@ your top-level `package.json` to add the reference to this new workspace: The workspaces init also supports the `npm init -w ` syntax, following the same set of rules explained earlier in the initial -**Description** section of this page. Similar to the previous example of -creating a new React-based project using -[`create-react-app`](https://npm.im/create-react-app), the following syntax -will make sure to create the new react app as a nested **workspace** within your -project and configure your `package.json` to recognize it as such: +**Description** section of this page. +Similar to the previous example of creating a new React-based project using +[`create-react-app`](https://npm.im/create-react-app), the following syntax will make sure to create the new react app as a nested **workspace** within your project and configure your `package.json` to recognize it as such: ```bash npm init -w packages/my-react-app react-app . ``` -This will make sure to generate your react app as expected, one important -consideration to have in mind is that `npm exec` is going to be run in the -context of the newly created folder for that workspace, and that's the reason -why in this example the initializer uses the initializer name followed with a -dot to represent the current directory in that context, e.g: `react-app .`: +This will make sure to generate your react app as expected, one important consideration to have in mind is that `npm exec` is going to be run in the context of the newly created folder for that workspace, and that's the reason why in this example the initializer uses the initializer name followed with a dot to represent the current directory in that context, e.g: `react-app .`: ``` . diff --git a/docs/lib/content/commands/npm-install-test.md b/docs/lib/content/commands/npm-install-test.md index 4a2798b41be29..33c988a6d82c7 100644 --- a/docs/lib/content/commands/npm-install-test.md +++ b/docs/lib/content/commands/npm-install-test.md @@ -10,8 +10,8 @@ description: Install package(s) and run tests ### Description -This command runs an `npm install` followed immediately by an `npm test`. It -takes exactly the same arguments as `npm install`. +This command runs an `npm install` followed immediately by an `npm test`. +It takes exactly the same arguments as `npm install`. ### Configuration diff --git a/docs/lib/content/commands/npm-install.md b/docs/lib/content/commands/npm-install.md index e77a6fa157aa4..9e4996d51373c 100644 --- a/docs/lib/content/commands/npm-install.md +++ b/docs/lib/content/commands/npm-install.md @@ -10,10 +10,8 @@ description: Install a package ### Description -This command installs a package and any packages that it depends on. If the -package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, -the installation of dependencies will be driven by that, respecting the -following order of precedence: +This command installs a package and any packages that it depends on. +If the package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, the installation of dependencies will be driven by that, respecting the following order of precedence: * `npm-shrinkwrap.json` * `package-lock.json` @@ -35,39 +33,26 @@ A `package` is: * f) a `` that has a "latest" tag satisfying (e) * g) a `` that resolves to (a) -Even if you never publish your package, you can still get a lot of benefits -of using npm if you just want to write a node program (a), and perhaps if -you also want to be able to easily install it elsewhere after packing it up -into a tarball (b). +Even if you never publish your package, you can still get a lot of benefits of using npm if you just want to write a node program (a), and perhaps if you also want to be able to easily install it elsewhere after packing it up into a tarball (b). * `npm install` (in a package directory, no arguments): Install the dependencies to the local `node_modules` folder. - In global mode (ie, with `-g` or `--global` appended to the command), - it installs the current package context (ie, the current working - directory) as a global package. + In global mode (ie, with `-g` or `--global` appended to the command), it installs the current package context (ie, the current working directory) as a global package. - By default, `npm install` will install all modules listed as - dependencies in [`package.json`](/configuring-npm/package-json). + By default, `npm install` will install all modules listed as dependencies in [`package.json`](/configuring-npm/package-json). - With the `--production` flag (or when the `NODE_ENV` environment - variable is set to `production`), npm will not install modules listed - in `devDependencies`. To install all modules listed in both - `dependencies` and `devDependencies` when `NODE_ENV` environment - variable is set to `production`, you can use `--production=false`. + With the `--production` flag (or when the `NODE_ENV` environment variable is set to `production`), npm will not install modules listed in `devDependencies`. + To install all modules listed in both `dependencies` and `devDependencies` when `NODE_ENV` environment variable is set to `production`, you can use `--production=false`. - > NOTE: The `--production` flag has no particular meaning when adding a - dependency to a project. + > NOTE: The `--production` flag has no particular meaning when adding a dependency to a project. * `npm install `: - If `` sits inside the root of your project, its dependencies will be installed and may - be hoisted to the top-level `node_modules` as they would for other - types of dependencies. If `` sits outside the root of your project, - *npm will not install the package dependencies* in the directory ``, - but it will create a symlink to ``. + If `` sits inside the root of your project, its dependencies will be installed and may be hoisted to the top-level `node_modules` as they would for other types of dependencies. + If `` sits outside the root of your project, *npm will not install the package dependencies* in the directory ``, but it will create a symlink to ``. > NOTE: If you want to install the content of a directory like a package from the registry instead of creating a link, you would need to use the `--install-links` option. @@ -80,19 +65,14 @@ into a tarball (b). * `npm install `: - Install a package that is sitting on the filesystem. Note: if you just - want to link a dev directory into your npm root, you can do this more - easily by using [`npm link`](/commands/npm-link). + Install a package that is sitting on the filesystem. + Note: if you just want to link a dev directory into your npm root, you can do this more easily by using [`npm link`](/commands/npm-link). Tarball requirements: - * The filename *must* use `.tar`, `.tar.gz`, or `.tgz` as the - extension. - * The package contents should reside in a subfolder inside the tarball - (usually it is called `package/`). npm strips one directory layer - when installing the package (an equivalent of `tar x - --strip-components=1` is run). - * The package must contain a `package.json` file with `name` and - `version` properties. + * The filename *must* use `.tar`, `.tar.gz`, or `.tgz` as the extension. + * The package contents should reside in a subfolder inside the tarball (usually it is called `package/`). + npm strips one directory layer when installing the package (an equivalent of `tar x --strip-components=1` is run). + * The package must contain a `package.json` file with `name` and `version` properties. Example: @@ -102,8 +82,8 @@ into a tarball (b). * `npm install `: - Fetch the tarball url, and then install it. In order to distinguish between - this and other options, the argument must start with "http://" or "https://" + Fetch the tarball url, and then install it. + In order to distinguish between this and other options, the argument must start with "http://" or "https://" Example: @@ -113,11 +93,11 @@ into a tarball (b). * `npm install [<@scope>/]`: - Do a `@` install, where `` is the "tag" config. (See - [`config`](/using-npm/config#tag). The config's default value is `latest`.) + Do a `@` install, where `` is the "tag" config. + (See [`config`](/using-npm/config#tag). + The config's default value is `latest`.) - In most cases, this will install the version of the modules tagged as - `latest` on the npm registry. + In most cases, this will install the version of the modules tagged as `latest` on the npm registry. Example: @@ -126,11 +106,10 @@ into a tarball (b). ``` `npm install` saves any specified packages into `dependencies` by default. - Additionally, you can control where and how they get saved with some - additional flags: + Additionally, you can control where and how they get saved with some additional flags: - * `-P, --save-prod`: Package will appear in your `dependencies`. This - is the default unless `-D` or `-O` are present. + * `-P, --save-prod`: Package will appear in your `dependencies`. + This is the default unless `-D` or `-O` are present. * `-D, --save-dev`: Package will appear in your `devDependencies`. @@ -141,26 +120,21 @@ into a tarball (b). * `--no-save`: Prevents saving to `dependencies`. - When using any of the above options to save dependencies to your - package.json, there are two additional, optional flags: + When using any of the above options to save dependencies to your package.json, there are two additional, optional flags: - * `-E, --save-exact`: Saved dependencies will be configured with an - exact version rather than using npm's default semver range operator. + * `-E, --save-exact`: Saved dependencies will be configured with an exact version rather than using npm's default semver range operator. - * `-B, --save-bundle`: Saved dependencies will also be added to your - `bundleDependencies` list. + * `-B, --save-bundle`: Saved dependencies will also be added to your `bundleDependencies` list. - Further, if you have an `npm-shrinkwrap.json` or `package-lock.json` - then it will be updated as well. + Further, if you have an `npm-shrinkwrap.json` or `package-lock.json` then it will be updated as well. - `` is optional. The package will be downloaded from the registry - associated with the specified scope. If no registry is associated with - the given scope the default registry is assumed. See - [`scope`](/using-npm/scope). + `` is optional. + The package will be downloaded from the registry associated with the specified scope. + If no registry is associated with the given scope the default registry is assumed. + See [`scope`](/using-npm/scope). - Note: if you do not include the @-symbol on your scope name, npm will - interpret this as a GitHub repository instead, see below. Scopes names - must also be followed by a slash. + Note: if you do not include the @-symbol on your scope name, npm will interpret this as a GitHub repository instead, see below. + Scopes names must also be followed by a slash. Examples: @@ -176,13 +150,10 @@ into a tarball (b). * `npm install @npm:`: - Install a package under a custom alias. Allows multiple versions of - a same-name package side-by-side, more convenient import names for - packages with otherwise long ones, and using git forks replacements - or forked npm packages as replacements. Aliasing works only on your - project and does not rename packages in transitive dependencies. - Aliases should follow the naming conventions stated in - [`validate-npm-package-name`](https://www.npmjs.com/package/validate-npm-package-name#naming-rules). + Install a package under a custom alias. + Allows multiple versions of a same-name package side-by-side, more convenient import names for packages with otherwise long ones, and using git forks replacements or forked npm packages as replacements. + Aliasing works only on your project and does not rename packages in transitive dependencies. + Aliases should follow the naming conventions stated in [`validate-npm-package-name`](https://www.npmjs.com/package/validate-npm-package-name#naming-rules). Examples: @@ -196,8 +167,7 @@ into a tarball (b). * `npm install [<@scope>/]@`: Install the version of the package that is referenced by the specified tag. - If the tag does not exist in the registry data for that package, then this - will fail. + If the tag does not exist in the registry data for that package, then this will fail. Example: @@ -208,8 +178,8 @@ into a tarball (b). * `npm install [<@scope>/]@`: - Install the specified version of the package. This will fail if the - version has not been published to the registry. + Install the specified version of the package. + This will fail if the version has not been published to the registry. Example: @@ -221,11 +191,9 @@ into a tarball (b). * `npm install [<@scope>/]@`: Install a version of the package matching the specified version range. - This will follow the same rules for resolving dependencies described in - [`package.json`](/configuring-npm/package-json). + This will follow the same rules for resolving dependencies described in [`package.json`](/configuring-npm/package-json). - Note that most version ranges must be put in quotes so that your shell - will treat it as a single argument. + Note that most version ranges must be put in quotes so that your shell will treat it as a single argument. Example: @@ -236,8 +204,8 @@ into a tarball (b). * `npm install `: - Installs the package from the hosted git provider, cloning it with - `git`. For a full git remote url, only that URL will be attempted. + Installs the package from the hosted git provider, cloning it with `git`. + For a full git remote url, only that URL will be attempted. ```bash ://[[:]@][:][:][/][# | #semver:] @@ -246,23 +214,15 @@ into a tarball (b). `` is one of `git`, `git+ssh`, `git+http`, `git+https`, or `git+file`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#semver:`, `` - can be any valid semver range or exact version, and npm will look for - any tags or refs matching that range in the remote repository, much as - it would for a registry dependency. If neither `#` or - `#semver:` is specified, then the default branch of the - repository is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#semver:`, `` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. + If neither `#` or `#semver:` is specified, then the default branch of the repository is used. - If the repository makes use of submodules, those submodules will be - cloned as well. + If the repository makes use of submodules, those submodules will be cloned as well. - If the package being installed contains a `prepare` script, its - `dependencies` and `devDependencies` will be installed, and the prepare - script will be run, before the package is packaged and installed. + If the package being installed contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed. - The following git environment variables are recognized by npm and will - be added to the environment when running git: + The following git environment variables are recognized by npm and will be added to the environment when running git: * `GIT_ASKPASS` * `GIT_EXEC_PATH` @@ -288,19 +248,13 @@ into a tarball (b). * `npm install /[#]`: * `npm install github:/[#]`: - Install the package at `https://github.com/githubname/githubrepo` by - attempting to clone it using `git`. + Install the package at `https://github.com/githubname/githubrepo` by attempting to clone it using `git`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#semver:`, `` - can be any valid semver range or exact version, and npm will look for - any tags or refs matching that range in the remote repository, much as - it would for a registry dependency. If neither `#` or - `#semver:` is specified, then the default branch is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#semver:`, `` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. + If neither `#` or `#semver:` is specified, then the default branch is used. - As with regular git dependencies, `dependencies` and `devDependencies` - will be installed if the package has a `prepare` script before the - package is done installing. + As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing. Examples: @@ -311,13 +265,10 @@ into a tarball (b). * `npm install gist:[/][#|#semver:]`: - Install the package at `https://gist.github.com/gistID` by attempting to - clone it using `git`. The GitHub username associated with the gist is - optional and will not be saved in `package.json`. + Install the package at `https://gist.github.com/gistID` by attempting to clone it using `git`. + The GitHub username associated with the gist is optional and will not be saved in `package.json`. - As with regular git dependencies, `dependencies` and `devDependencies` will - be installed if the package has a `prepare` script before the package is - done installing. + As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing. Example: @@ -327,19 +278,13 @@ into a tarball (b). * `npm install bitbucket:/[#]`: - Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo` - by attempting to clone it using `git`. + Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo` by attempting to clone it using `git`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#semver:`, `` can - be any valid semver range or exact version, and npm will look for any tags - or refs matching that range in the remote repository, much as it would for a - registry dependency. If neither `#` or `#semver:` is - specified, then `master` is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#semver:`, `` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. + If neither `#` or `#semver:` is specified, then `master` is used. - As with regular git dependencies, `dependencies` and `devDependencies` will - be installed if the package has a `prepare` script before the package is - done installing. + As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing. Example: @@ -349,19 +294,13 @@ into a tarball (b). * `npm install gitlab:/[#]`: - Install the package at `https://gitlab.com/gitlabname/gitlabrepo` - by attempting to clone it using `git`. + Install the package at `https://gitlab.com/gitlabname/gitlabrepo` by attempting to clone it using `git`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#semver:`, `` can - be any valid semver range or exact version, and npm will look for any tags - or refs matching that range in the remote repository, much as it would for a - registry dependency. If neither `#` or `#semver:` is - specified, then `master` is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#semver:`, `` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. + If neither `#` or `#semver:` is specified, then `master` is used. - As with regular git dependencies, `dependencies` and `devDependencies` will - be installed if the package has a `prepare` script before the package is - done installing. + As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing. Example: @@ -377,19 +316,14 @@ For example: npm install sax@">=0.1.0 <0.2.0" bench supervisor ``` -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. +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. -The `--dry-run` argument will report in the usual way what the install -would have done without actually installing anything. +The `--dry-run` argument will report in the usual way what the install would have done without actually installing anything. -The `--package-lock-only` argument will only update the -`package-lock.json`, instead of checking `node_modules` and downloading -dependencies. +The `--package-lock-only` argument will only update the `package-lock.json`, instead of checking `node_modules` and downloading dependencies. -The `-f` or `--force` argument will force npm to fetch remote resources -even if a local copy exists on disk. +The `-f` or `--force` argument will force npm to fetch remote resources even if a local copy exists on disk. ```bash npm install sax --force @@ -397,9 +331,8 @@ npm install sax --force ### Configuration -See the [`config`](/using-npm/config) help doc. Many of the configuration -params have some effect on installation, since that's most of what npm -does. +See the [`config`](/using-npm/config) help doc. +Many of the configuration params have some effect on installation, since that's most of what npm does. These are some of the most common options related to installation. @@ -407,8 +340,7 @@ These are some of the most common options related to installation. ### Algorithm -Given a `package{dep}` structure: `A{B,C}, B{C}, C{D}`, -the npm install algorithm produces: +Given a `package{dep}` structure: `A{B,C}, B{C}, C{D}`, the npm install algorithm produces: ```bash A @@ -417,9 +349,8 @@ A +-- D ``` -That is, the dependency from B to C is satisfied by the fact that A already -caused C to be installed at a higher level. D is still installed at the top -level because nothing conflicts with it. +That is, the dependency from B to C is satisfied by the fact that A already caused C to be installed at a higher level. +D is still installed at the top level because nothing conflicts with it. For `A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces: @@ -431,13 +362,10 @@ A +-- D@1 ``` -Because B's D@1 will be installed in the top-level, C now has to install -D@2 privately for itself. This algorithm is deterministic, but different -trees may be produced if two dependencies are requested for installation in -a different order. +Because B's D@1 will be installed in the top-level, C now has to install D@2 privately for itself. +This algorithm is deterministic, but different trees may be produced if two dependencies are requested for installation in a different order. -See [folders](/configuring-npm/folders) for a more detailed description of -the specific folder structures that npm creates. +See [folders](/configuring-npm/folders) for a more detailed description of the specific folder structures that npm creates. ### See Also diff --git a/docs/lib/content/commands/npm-link.md b/docs/lib/content/commands/npm-link.md index 232e55ff9fcd9..05aff5314e65a 100644 --- a/docs/lib/content/commands/npm-link.md +++ b/docs/lib/content/commands/npm-link.md @@ -10,31 +10,25 @@ description: Symlink a package folder ### Description -This is handy for installing your own stuff, so that you can work on it and -test iteratively without having to continually rebuild. +This is handy for installing your own stuff, so that you can work on it and test iteratively without having to continually rebuild. Package linking is a two-step process. -First, `npm link` in a package folder with no arguments will create a -symlink in the global folder `{prefix}/lib/node_modules/` that -links to the package where the `npm link` command was executed. It will -also link any bins in the package to `{prefix}/bin/{name}`. Note that -`npm link` uses the global prefix (see `npm prefix -g` for its value). +First, `npm link` in a package folder with no arguments will create a symlink in the global folder `{prefix}/lib/node_modules/` that links to the package where the `npm link` command was executed. +It will also link any bins in the package to `{prefix}/bin/{name}`. +Note that `npm link` uses the global prefix (see `npm prefix -g` for its value). -Next, in some other location, `npm link package-name` will create a -symbolic link from globally-installed `package-name` to `node_modules/` of -the current folder. +Next, in some other location, `npm link package-name` will create a symbolic link from globally-installed `package-name` to `node_modules/` of the current folder. -Note that `package-name` is taken from `package.json`, _not_ from the -directory name. +Note that `package-name` is taken from `package.json`, _not_ from the directory name. -The package name can be optionally prefixed with a scope. See -[`scope`](/using-npm/scope). The scope must be preceded by an @-symbol and -followed by a slash. +The package name can be optionally prefixed with a scope. +See +[`scope`](/using-npm/scope). +The scope must be preceded by an @-symbol and followed by a slash. When creating tarballs for `npm publish`, the linked packages are -"snapshotted" to their current state by resolving the symbolic links, if -they are included in `bundleDependencies`. +"snapshotted" to their current state by resolving the symbolic links, if they are included in `bundleDependencies`. For example: @@ -46,11 +40,11 @@ npm link redis # link-install the package ``` Now, any changes to `~/projects/node-redis` will be reflected in -`~/projects/node-bloggy/node_modules/node-redis/`. Note that the link -should be to the package name, not the directory name for that package. +`~/projects/node-bloggy/node_modules/node-redis/`. +Note that the link should be to the package name, not the directory name for that package. -You may also shortcut the two steps in one. For example, to do the -above use-case in a shorter way: +You may also shortcut the two steps in one. +For example, to do the above use-case in a shorter way: ```bash cd ~/projects/node-bloggy # go into the dir of your main project @@ -64,14 +58,12 @@ The second line is the equivalent of doing: npm link redis ``` -That is, it first creates a global link, and then links the global -installation target into your project's `node_modules` folder. +That is, it first creates a global link, and then links the global installation target into your project's `node_modules` folder. Note that in this case, you are referring to the directory name, `node-redis`, rather than the package name `redis`. -If your linked package is scoped (see [`scope`](/using-npm/scope)) your -link command must include that scope, e.g. +If your linked package is scoped (see [`scope`](/using-npm/scope)) your link command must include that scope, e.g. ```bash npm link @myorg/privatepackage @@ -79,30 +71,21 @@ npm link @myorg/privatepackage ### Caveat -Note that package dependencies linked in this way are _not_ saved to -`package.json` by default, on the assumption that the intention is to have -a link stand in for a regular non-link dependency. Otherwise, for example, -if you depend on `redis@^3.0.1`, and ran `npm link redis`, it would replace -the `^3.0.1` dependency with `file:../path/to/node-redis`, which you -probably don't want! Additionally, other users or developers on your -project would run into issues if they do not have their folders set up -exactly the same as yours. +Note that package dependencies linked in this way are _not_ saved to `package.json` by default, on the assumption that the intention is to have +a link stand in for a regular non-link dependency. +Otherwise, for example, +if you depend on `redis@^3.0.1`, and ran `npm link redis`, it would replace the `^3.0.1` dependency with `file:../path/to/node-redis`, which you probably don't want! Additionally, other users or developers on your project would run into issues if they do not have their folders set up exactly the same as yours. -If you are adding a _new_ dependency as a link, you should add it to the -relevant metadata by running `npm install --package-lock-only`. +If you are adding a _new_ dependency as a link, you should add it to the relevant metadata by running `npm install --package-lock-only`. -If you _want_ to save the `file:` reference in your `package.json` and -`package-lock.json` files, you can use `npm link --save` to do so. +If you _want_ to save the `file:` reference in your `package.json` and `package-lock.json` files, you can use `npm link --save` to do so. ### Workspace Usage -`npm link --workspace ` will link the relevant package as a -dependency of the specified workspace(s). Note that It may actually be -linked into the parent project's `node_modules` folder, if there are no -conflicting dependencies. +`npm link --workspace ` will link the relevant package as a dependency of the specified workspace(s). +Note that It may actually be linked into the parent project's `node_modules` folder, if there are no conflicting dependencies. -`npm link --workspace ` will create a global link to the specified -workspace(s). +`npm link --workspace ` will create a global link to the specified workspace(s). ### Configuration diff --git a/docs/lib/content/commands/npm-login.md b/docs/lib/content/commands/npm-login.md index 45dd04abdbad4..1c8e744e0b8da 100644 --- a/docs/lib/content/commands/npm-login.md +++ b/docs/lib/content/commands/npm-login.md @@ -11,22 +11,21 @@ description: Login to a registry user account ### Description Verify a user in the specified registry, and save the credentials to the -`.npmrc` file. If no registry is specified, the default registry will be -used (see [`config`](/using-npm/config)). +`.npmrc` file. +If no registry is specified, the default registry will be used (see [`config`](/using-npm/config)). -When you run `npm login`, the CLI automatically generates a legacy token of `publish` type. For more information, see [About legacy tokens](/about-access-tokens#about-legacy-tokens). +When you run `npm login`, the CLI automatically generates a legacy token of `publish` type. +For more information, see [About legacy tokens](/about-access-tokens#about-legacy-tokens). -When using `legacy` for your `auth-type`, the username and password, are -read in from prompts. +When using `legacy` for your `auth-type`, the username and password, are read in from prompts. To reset your password, go to To change your email address, go to -You may use this command multiple times with the same user account to -authorize on a new machine. When authenticating on a new machine, -the username, password and email address must all match with -your existing record. +You may use this command multiple times with the same user account to authorize on a new machine. +When authenticating on a new machine, +the username, password and email address must all match with your existing record. ### Configuration diff --git a/docs/lib/content/commands/npm-logout.md b/docs/lib/content/commands/npm-logout.md index 61f0219a19e11..4d31727bb02d5 100644 --- a/docs/lib/content/commands/npm-logout.md +++ b/docs/lib/content/commands/npm-logout.md @@ -10,16 +10,13 @@ description: Log out of the registry ### Description -When logged into a registry that supports token-based authentication, tell -the server to end this token's session. This will invalidate the token -everywhere you're using it, not just for the current environment. +When logged into a registry that supports token-based authentication, tell the server to end this token's session. +This will invalidate the token everywhere you're using it, not just for the current environment. -When logged into a legacy registry that uses username and password -authentication, this will clear the credentials in your user configuration. +When logged into a legacy registry that uses username and password authentication, this will clear the credentials in your user configuration. In this case, it will _only_ affect the current environment. -If `--scope` is provided, this will find the credentials for the registry -connected to that scope, if set. +If `--scope` is provided, this will find the credentials for the registry connected to that scope, if set. ### Configuration diff --git a/docs/lib/content/commands/npm-ls.md b/docs/lib/content/commands/npm-ls.md index 694b8744c45ea..e2fafbc7807fb 100644 --- a/docs/lib/content/commands/npm-ls.md +++ b/docs/lib/content/commands/npm-ls.md @@ -10,17 +10,13 @@ description: List installed packages ### Description -This command will print to stdout all the versions of packages that are -installed, as well as their dependencies when `--all` is specified, in a -tree structure. +This command will print to stdout all the versions of packages that are installed, as well as their dependencies when `--all` is specified, in a tree structure. -Note: to get a "bottoms up" view of why a given package is included in the -tree at all, use [`npm explain`](/commands/npm-explain). +Note: to get a "bottoms up" view of why a given package is included in the tree at all, use [`npm explain`](/commands/npm-explain). -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: +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@@VERSION@ /path/to/npm @@ -30,12 +26,9 @@ npm@@VERSION@ /path/to/npm It will print out extraneous, missing, and invalid packages. -If a project specifies git urls for dependencies these are shown -in parentheses after the `name@version` to make it easier for users to -recognize potential forks of a project. +If a project specifies git urls for dependencies these are shown in parentheses after the `name@version` to make it easier for users to recognize potential forks of a project. -The tree shown is the logical dependency tree, based on package -dependencies, not the physical layout of your `node_modules` folder. +The tree shown is the logical dependency tree, based on package dependencies, not the physical layout of your `node_modules` folder. When run as `ll` or `la`, it shows extended information by default. diff --git a/docs/lib/content/commands/npm-org.md b/docs/lib/content/commands/npm-org.md index cc12bf9573a84..d866c75aead61 100644 --- a/docs/lib/content/commands/npm-org.md +++ b/docs/lib/content/commands/npm-org.md @@ -48,8 +48,8 @@ $ npm org ls my-org @mx-santos ### Description -You can use the `npm org` commands to manage and view users of an -organization. It supports adding and removing users, changing their roles, +You can use the `npm org` commands to manage and view users of an organization. +It supports adding and removing users, changing their roles, listing them, and finding specific ones and their roles. ### Configuration diff --git a/docs/lib/content/commands/npm-outdated.md b/docs/lib/content/commands/npm-outdated.md index a62f943b13e6b..40da7c3146f28 100644 --- a/docs/lib/content/commands/npm-outdated.md +++ b/docs/lib/content/commands/npm-outdated.md @@ -10,39 +10,26 @@ description: Check for outdated packages ### Description -This command will check the registry to see if any (or, specific) installed -packages are currently outdated. +This command will check the registry to see if any (or, specific) installed packages are currently outdated. -By default, only the direct dependencies of the root project and direct -dependencies of your configured *workspaces* are shown. +By default, only the direct dependencies of the root project and direct dependencies of your configured *workspaces* are shown. Use `--all` to find all outdated meta-dependencies as well. In the output: -* `wanted` is the maximum version of the package that satisfies the semver - range specified in `package.json`. If there's no available semver range - (i.e. you're running `npm outdated --global`, or the package isn't - included in `package.json`), then `wanted` shows the currently-installed - version. +* `wanted` is the maximum version of the package that satisfies the semver range specified in `package.json`. + If there's no available semver range (i.e. you're running `npm outdated --global`, or the package isn't included in `package.json`), then `wanted` shows the currently-installed version. * `latest` is the version of the package tagged as latest in the registry. - Running `npm publish` with no special configuration will publish the - package with a dist-tag of `latest`. This may or may not be the maximum - version of the package, or the most-recently published version of the - package, depending on how the package's developer manages the latest - [dist-tag](/commands/npm-dist-tag). + Running `npm publish` with no special configuration will publish the package with a dist-tag of `latest`. + This may or may not be the maximum version of the package, or the most-recently published version of the package, depending on how the package's developer manages the latest [dist-tag](/commands/npm-dist-tag). * `location` is where in the physical tree the package is located. * `depended by` shows which package depends on the displayed dependency -* `package type` (when using `--long` / `-l`) tells you whether this - package is a `dependency` or a dev/peer/optional dependency. Packages not - included in `package.json` are always marked `dependencies`. -* `homepage` (when using `--long` / `-l`) is the `homepage` value contained - in the package's packument +* `package type` (when using `--long` / `-l`) tells you whether this package is a `dependency` or a dev/peer/optional dependency. + Packages not included in `package.json` are always marked `dependencies`. +* `homepage` (when using `--long` / `-l`) is the `homepage` value contained in the package's packument * `depended by location` (when using `--long` / `-l`) shows location of the package that depends on the displayed dependency -* Red means there's a newer version matching your semver requirements, so - you should update now. -* Yellow indicates that there's a newer version _above_ your semver - requirements (usually new major, or new 0.x minor) so proceed with - caution. +* Red means there's a newer version matching your semver requirements, so you should update now. +* Yellow indicates that there's a newer version _above_ your semver requirements (usually new major, or new 0.x minor) so proceed with caution. ### An example @@ -68,20 +55,14 @@ With these `dependencies`: A few things to note: -* `glob` requires `^5`, which prevents npm from installing `glob@6`, which - is outside the semver range. -* Git dependencies will always be reinstalled, because of how they're - specified. The installed committish might satisfy the dependency - specifier (if it's something immutable, like a commit SHA), or it might - not, so `npm outdated` and `npm update` have to fetch Git repos to check. - This is why currently doing a reinstall of a Git dependency always forces - a new clone and install. -* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because - npm uses dist-tags to manage its `latest` and `next` release channels. - `npm update` will install the _newest_ version, but `npm install npm` - (with no semver range) will install whatever's tagged as `latest`. -* `once` is just plain out of date. Reinstalling `node_modules` from - scratch or running `npm update` will bring it up to spec. +* `glob` requires `^5`, which prevents npm from installing `glob@6`, which is outside the semver range. +* Git dependencies will always be reinstalled, because of how they're specified. + The installed committish might satisfy the dependency specifier (if it's something immutable, like a commit SHA), or it might not, so `npm outdated` and `npm update` have to fetch Git repos to check. + This is why currently doing a reinstall of a Git dependency always forces a new clone and install. +* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm uses dist-tags to manage its `latest` and `next` release channels. + `npm update` will install the _newest_ version, but `npm install npm` (with no semver range) will install whatever's tagged as `latest`. +* `once` is just plain out of date. + Reinstalling `node_modules` from scratch or running `npm update` will bring it up to spec. ### Configuration diff --git a/docs/lib/content/commands/npm-owner.md b/docs/lib/content/commands/npm-owner.md index 9ff67b5784c59..a803111802eb4 100644 --- a/docs/lib/content/commands/npm-owner.md +++ b/docs/lib/content/commands/npm-owner.md @@ -13,19 +13,22 @@ description: Manage package owners Manage ownership of published packages. * ls: List all the users who have access to modify a package and push new - versions. Handy when you need to know who to bug for help. -* add: Add a new user as a maintainer of a package. This user is enabled + versions. +Handy when you need to know who to bug for help. +* add: Add a new user as a maintainer of a package. +This user is enabled to modify metadata, publish new versions, and add other owners. -* rm: Remove a user from the package owner list. This immediately revokes +* rm: Remove a user from the package owner list. +This immediately revokes their privileges. -Note that there is only one level of access. Either you can modify a package, -or you can't. Future versions may contain more fine-grained access levels, but -that is not implemented at this time. +Note that there is only one level of access. +Either you can modify a package, +or you can't. +Future versions may contain more fine-grained access levels, but that is not implemented at this time. If you have two-factor authentication enabled with `auth-and-writes` (see -[`npm-profile`](/commands/npm-profile)) then you'll need to go through a second factor -flow when changing ownership or include an otp on the command line with `--otp`. +[`npm-profile`](/commands/npm-profile)) then you'll need to go through a second factor flow when changing ownership or include an otp on the command line with `--otp`. ### Configuration diff --git a/docs/lib/content/commands/npm-pack.md b/docs/lib/content/commands/npm-pack.md index 0793ee2d39217..b5f39bcc1ead0 100644 --- a/docs/lib/content/commands/npm-pack.md +++ b/docs/lib/content/commands/npm-pack.md @@ -14,14 +14,9 @@ description: Create a tarball from a package ### Description -For anything that's installable (that is, a package folder, tarball, -tarball url, git url, name@tag, name@version, name, or scoped name), this -command will fetch it to the cache, copy the tarball to the current working -directory as `-.tgz`, and then write the filenames out to -stdout. - -If the same package is specified multiple times, then the file will be -overwritten the second time. +For anything that's installable (that is, a package folder, tarball, tarball url, git url, name@tag, name@version, name, or scoped name), this command will fetch it to the cache, copy the tarball to the current working directory as `-.tgz`, and then write the filenames out to stdout. + +If the same package is specified multiple times, then the file will be overwritten the second time. If no arguments are supplied, then npm packs the current package folder. diff --git a/docs/lib/content/commands/npm-pkg.md b/docs/lib/content/commands/npm-pkg.md index ae49409f81f2e..6379c6575b1c4 100644 --- a/docs/lib/content/commands/npm-pkg.md +++ b/docs/lib/content/commands/npm-pkg.md @@ -11,13 +11,9 @@ description: Manages your package.json ### Description A command that automates the management of `package.json` files. -`npm pkg` provide 3 different sub commands that allow you to modify or retrieve -values for given object keys in your `package.json`. +`npm pkg` provide 3 different sub commands that allow you to modify or retrieve values for given object keys in your `package.json`. -The syntax to retrieve and set fields is a dot separated representation of -the nested object properties to be found within your `package.json`, it's the -same notation used in [`npm view`](/commands/npm-view) to retrieve information -from the registry manifest, below you can find more examples on how to use it. +The syntax to retrieve and set fields is a dot separated representation of the nested object properties to be found within your `package.json`, it's the same notation used in [`npm view`](/commands/npm-view) to retrieve information from the registry manifest, below you can find more examples on how to use it. Returned values are always in **json** format. @@ -25,8 +21,7 @@ Returned values are always in **json** format. Retrieves a value `key`, defined in your `package.json` file. - For example, in order to retrieve the name of the current package, you - can run: + For example, in order to retrieve the name of the current package, you can run: ```bash npm pkg get name @@ -38,32 +33,29 @@ Returned values are always in **json** format. npm pkg get name version ``` - You can view child fields by separating them with a period. To retrieve - the value of a test `script` value, you would run the following command: + You can view child fields by separating them with a period. + To retrieve the value of a test `script` value, you would run the following command: ```bash npm pkg get scripts.test ``` - For fields that are arrays, requesting a non-numeric field will return - all of the values from the objects in the list. For example, to get all - the contributor emails for a package, you would run: + For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. + For example, to get all the contributor emails for a package, you would run: ```bash npm pkg get contributors.email ``` - You may also use numeric indices in square braces to specifically select - an item in an array field. To just get the email address of the first - contributor in the list, you can run: + You may also use numeric indices in square braces to specifically select an item in an array field. + To just get the email address of the first contributor in the list, you can run: ```bash npm pkg get contributors[0].email ``` - For complex fields you can also name a property in square brackets - to specifically select a child field. This is especially helpful - with the exports object: + For complex fields you can also name a property in square brackets to specifically select a child field. + This is especially helpful with the exports object: ```bash npm pkg get "exports[.].require" @@ -71,19 +63,12 @@ Returned values are always in **json** format. * `npm pkg set =` - Sets a `value` in your `package.json` based on the `field` value. When - saving to your `package.json` file the same set of rules used during - `npm install` and other cli commands that touches the `package.json` file - are used, making sure to respect the existing indentation and possibly - applying some validation prior to saving values to the file. + Sets a `value` in your `package.json` based on the `field` value. + When saving to your `package.json` file the same set of rules used during `npm install` and other cli commands that touches the `package.json` file are used, making sure to respect the existing indentation and possibly applying some validation prior to saving values to the file. - The same syntax used to retrieve values from your package can also be used - to define new properties or overriding existing ones, below are some - examples of how the dot separated syntax can be used to edit your - `package.json` file. + The same syntax used to retrieve values from your package can also be used to define new properties or overriding existing ones, below are some examples of how the dot separated syntax can be used to edit your `package.json` file. - Defining a new bin named `mynewcommand` in your `package.json` that points - to a file `cli.js`: + Defining a new bin named `mynewcommand` in your `package.json` that points to a file `cli.js`: ```bash npm pkg set bin.mynewcommand=cli.js @@ -95,23 +80,19 @@ Returned values are always in **json** format. npm pkg set description='Awesome package' engines.node='>=10' ``` - It's also possible to add to array values, for example to add a new - contributor entry: + It's also possible to add to array values, for example to add a new contributor entry: ```bash npm pkg set contributors[0].name='Foo' contributors[0].email='foo@bar.ca' ``` - You may also append items to the end of an array using the special - empty bracket notation: + You may also append items to the end of an array using the special empty bracket notation: ```bash npm pkg set contributors[].name='Foo' contributors[].name='Bar' ``` - It's also possible to parse values as json prior to saving them to your - `package.json` file, for example in order to set a `"private": true` - property: + It's also possible to parse values as json prior to saving them to your `package.json` file, for example in order to set a `"private": true` property: ```bash npm pkg set private=true --json @@ -127,9 +108,8 @@ Returned values are always in **json** format. Deletes a `key` from your `package.json` - The same syntax used to set values from your package can also be used - to remove existing ones. For example, in order to remove a script named - build: + The same syntax used to set values from your package can also be used to remove existing ones. + For example, in order to remove a script named build: ```bash npm pkg delete scripts.build @@ -137,10 +117,8 @@ Returned values are always in **json** format. * `npm pkg fix` - Auto corrects common errors in your `package.json`. npm already - does this during `publish`, which leads to subtle (mostly harmless) - differences between the contents of your `package.json` file and the - manifest that npm uses during installation. + Auto corrects common errors in your `package.json`. + npm already does this during `publish`, which leads to subtle (mostly harmless) differences between the contents of your `package.json` file and the manifest that npm uses during installation. ### Workspaces support @@ -148,17 +126,13 @@ You can set/get/delete items across your configured workspaces by using the [`workspace`](/using-npm/config#workspace) or [`workspaces`](/using-npm/config#workspaces) config options. -For example, setting a `funding` value across all configured workspaces -of a project: +For example, setting a `funding` value across all configured workspaces of a project: ```bash npm pkg set funding=https://example.com --ws ``` -When using `npm pkg get` to retrieve info from your configured workspaces, the -returned result will be in a json format in which top level keys are the -names of each workspace, the values of these keys will be the result values -returned from each of the configured workspaces, e.g: +When using `npm pkg get` to retrieve info from your configured workspaces, the returned result will be in a json format in which top level keys are the names of each workspace, the values of these keys will be the result values returned from each of the configured workspaces, e.g: ``` npm pkg get name version --ws diff --git a/docs/lib/content/commands/npm-prefix.md b/docs/lib/content/commands/npm-prefix.md index 913e7eea3a7e8..c0615aa743e8b 100644 --- a/docs/lib/content/commands/npm-prefix.md +++ b/docs/lib/content/commands/npm-prefix.md @@ -10,11 +10,11 @@ description: Display prefix ### Description -Print the local prefix to standard output. This is the closest parent directory -to contain a `package.json` file or `node_modules` directory, unless `-g` is -also specified. +Print the local prefix to standard output. +This is the closest parent directory to contain a `package.json` file or `node_modules` directory, unless `-g` is also specified. -If `-g` is specified, this will be the value of the global prefix. See +If `-g` is specified, this will be the value of the global prefix. +See [`npm config`](/commands/npm-config) for more detail. ### Example diff --git a/docs/lib/content/commands/npm-profile.md b/docs/lib/content/commands/npm-profile.md index ba6613393d736..79dd965c705d0 100644 --- a/docs/lib/content/commands/npm-profile.md +++ b/docs/lib/content/commands/npm-profile.md @@ -10,12 +10,12 @@ description: Change settings on your registry profile ### Description -Change your profile information on the registry. Note that this command -depends on the registry implementation, so third-party registries may not -support this interface. +Change your profile information on the registry. +Note that this command depends on the registry implementation, so third-party registries may not support this interface. * `npm profile get []`: Display all of the properties of your - profile, or one or more specific properties. It looks like: + profile, or one or more specific properties. +It looks like: ``` name: example @@ -31,18 +31,24 @@ updated: 2017-10-02T21:29:45.922Z ``` * `npm profile set `: Set the value of a profile - property. You can set the following properties this way: email, fullname, + property. +You can set the following properties this way: email, fullname, homepage, freenode, twitter, github -* `npm profile set password`: Change your password. This is interactive, - you'll be prompted for your current password and a new password. You'll +* `npm profile set password`: Change your password. +This is interactive, + you'll be prompted for your current password and a new password. +You'll also be prompted for an OTP if you have two-factor authentication enabled. * `npm profile enable-2fa [auth-and-writes|auth-only]`: Enables two-factor - authentication. Defaults to `auth-and-writes` mode. Modes are: + authentication. +Defaults to `auth-and-writes` mode. +Modes are: * `auth-only`: Require an OTP when logging in or making changes to your - account's authentication. The OTP will be required on both the website + account's authentication. +The OTP will be required on both the website and the command line. * `auth-and-writes`: Requires an OTP at all the times `auth-only` does, and also requires one when publishing a module, setting the `latest` diff --git a/docs/lib/content/commands/npm-prune.md b/docs/lib/content/commands/npm-prune.md index d1f48a67be1bc..0bce8d7bff03a 100644 --- a/docs/lib/content/commands/npm-prune.md +++ b/docs/lib/content/commands/npm-prune.md @@ -10,25 +10,19 @@ description: Remove extraneous packages ### Description -This command removes "extraneous" packages. If a package name is provided, -then only packages matching one of the supplied names are removed. +This command removes "extraneous" packages. +If a package name is provided, then only packages matching one of the supplied names are removed. -Extraneous packages are those present in the `node_modules` folder that are -not listed as any package's dependency list. +Extraneous packages are those present in the `node_modules` folder that are not listed as any package's dependency list. -If the `--omit=dev` flag is specified or the `NODE_ENV` environment -variable is set to `production`, this command will remove the packages -specified in your `devDependencies`. +If the `--omit=dev` flag is specified or the `NODE_ENV` environment variable is set to `production`, this command will remove the packages specified in your `devDependencies`. If the `--dry-run` flag is used then no changes will actually be made. -If the `--json` flag is used, then the changes `npm prune` made (or would -have made with `--dry-run`) are printed as a JSON object. +If the `--json` flag is used, then the changes `npm prune` made (or would have made with `--dry-run`) are printed as a JSON object. -In normal operation, extraneous modules are pruned automatically, so you'll -only need this command with the `--production` flag. However, in the real -world, operation is not always "normal". When crashes or mistakes happen, -this command can help clean up any resulting garbage. +In normal operation, extraneous modules are pruned automatically, so you'll only need this command with the `--production` flag. +However, in the real world, operation is not always "normal". When crashes or mistakes happen, this command can help clean up any resulting garbage. ### Configuration diff --git a/docs/lib/content/commands/npm-publish.md b/docs/lib/content/commands/npm-publish.md index 78f5d5bdfc846..35e7a88349ed9 100644 --- a/docs/lib/content/commands/npm-publish.md +++ b/docs/lib/content/commands/npm-publish.md @@ -12,15 +12,13 @@ description: Publish a package Publishes a package to the registry so that it can be installed by name. -By default npm will publish to the public registry. This can be -overridden by specifying a different default registry or using a -[`scope`](/using-npm/scope) in the name, combined with a -scope-configured registry (see +By default npm will publish to the public registry. +This can be overridden by specifying a different default registry or using a +[`scope`](/using-npm/scope) in the name, combined with a scope-configured registry (see [`package.json`](/configuring-npm/package-json)). -A `package` is interpreted the same way as other commands (like -`npm install`) and can be: +A `package` is interpreted the same way as other commands (like `npm install`) and can be: * a) a folder containing a program described by a [`package.json`](/configuring-npm/package-json) file @@ -33,38 +31,35 @@ A `package` is interpreted the same way as other commands (like * f) a `` that has a "latest" tag satisfying (e) * g) a `` that resolves to (a) -The publish will fail if the package name and version combination already -exists in the specified registry. +The publish will fail if the package name and version combination already exists in the specified registry. -Once a package is published with a given name and version, that specific -name and version combination can never be used again, even if it is removed -with [`npm unpublish`](/commands/npm-unpublish). +Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with [`npm unpublish`](/commands/npm-unpublish). -As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the -tarball will be submitted to the registry during publication. Subsequent -installs will use the strongest supported algorithm to verify downloads. +As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. +Subsequent installs will use the strongest supported algorithm to verify downloads. -Similar to `--dry-run` see [`npm pack`](/commands/npm-pack), which figures -out the files to be included and packs them into a tarball to be uploaded -to the registry. +Similar to `--dry-run` see [`npm pack`](/commands/npm-pack), which figures out the files to be included and packs them into a tarball to be uploaded to the registry. ### Files included in package -To see what will be included in your package, run `npm pack --dry-run`. All -files are included by default, with the following exceptions: +To see what will be included in your package, run `npm pack --dry-run`. +All files are included by default, with the following exceptions: - Certain files that are relevant to package installation and distribution - are always included. For example, `package.json`, `README.md`, + are always included. +For example, `package.json`, `README.md`, `LICENSE`, and so on. - If there is a "files" list in [`package.json`](/configuring-npm/package-json), then only the files - specified will be included. (If directories are specified, then they + specified will be included. + (If directories are specified, then they will be walked recursively and their contents included, subject to the same ignore rules.) - If there is a `.gitignore` or `.npmignore` file, then ignored files in - that and all child directories will be excluded from the package. If + that and all child directories will be excluded from the package. +If _both_ files exist, then the `.gitignore` is ignored, and only the `.npmignore` is used. @@ -79,12 +74,9 @@ files are included by default, with the following exceptions: - Symbolic links are never included in npm packages. -See [`developers`](/using-npm/developers) for full details on what's -included in the published package, as well as details on how the package is -built. +See [`developers`](/using-npm/developers) for full details on what's included in the published package, as well as details on how the package is built. -See [`package.json`](/configuring-npm/package-json) for more info on -what can and can't be ignored. +See [`package.json`](/configuring-npm/package-json) for more info on what can and can't be ignored. ### Configuration diff --git a/docs/lib/content/commands/npm-query.md b/docs/lib/content/commands/npm-query.md index 490eccffcc4b3..815ca231afa94 100644 --- a/docs/lib/content/commands/npm-query.md +++ b/docs/lib/content/commands/npm-query.md @@ -10,8 +10,7 @@ description: Dependency selector query ### Description -The `npm query` command allows for usage of css selectors in order to retrieve -an array of dependency objects. +The `npm query` command allows for usage of css selectors in order to retrieve an array of dependency objects. ### Piping npm query to other commands @@ -136,21 +135,16 @@ npm query ":type(git)" | jq 'map(.name)' | xargs -I {} npm why {} ### Expecting a certain number of results -One common use of `npm query` is to make sure there is only one version of -a certain dependency in your tree. This is especially common for -ecosystems like that rely on `typescript` where having state split -across two different but identically-named packages causes bugs. You -can use the `--expect-results` or `--expect-result-count` in your setup -to ensure that npm will exit with an exit code if your tree doesn't look -like you want it to. +One common use of `npm query` is to make sure there is only one version of a certain dependency in your tree. +This is especially common for ecosystems like that rely on `typescript` where having state split across two different but identically-named packages causes bugs. +You can use the `--expect-results` or `--expect-result-count` in your setup to ensure that npm will exit with an exit code if your tree doesn't look like you want it to. ```sh $ npm query '#react' --expect-result-count=1 ``` -Perhaps you want to quickly check if there are any production -dependencies that could be updated: +Perhaps you want to quickly check if there are any production dependencies that could be updated: ```sh $ npm query ':root>:outdated(in-range).prod' --no-expect-results @@ -158,7 +152,8 @@ $ npm query ':root>:outdated(in-range).prod' --no-expect-results ### Package lock only mode -If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines). +If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. +This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines). ### Configuration diff --git a/docs/lib/content/commands/npm-rebuild.md b/docs/lib/content/commands/npm-rebuild.md index aee332e37d8a1..ed61ac8e8ffb7 100644 --- a/docs/lib/content/commands/npm-rebuild.md +++ b/docs/lib/content/commands/npm-rebuild.md @@ -32,7 +32,8 @@ If there is a `binding.gyp` file in the root of your package, then npm will use } ``` -This default behavior is suppressed if the `package.json` has its own `install` or `preinstall` scripts. It is also suppressed if the package specifies `"gypfile": false` +This default behavior is suppressed if the `package.json` has its own `install` or `preinstall` scripts. +It is also suppressed if the package specifies `"gypfile": false` ### Configuration diff --git a/docs/lib/content/commands/npm-repo.md b/docs/lib/content/commands/npm-repo.md index e5968b3378fac..e63940b0e2b84 100644 --- a/docs/lib/content/commands/npm-repo.md +++ b/docs/lib/content/commands/npm-repo.md @@ -10,11 +10,9 @@ description: Open package repository page in the browser ### Description -This command tries to guess at the likely location of a package's -repository URL, and then tries to open it using the -[`--browser` config](/using-npm/config#browser) param. If no package name is -provided, it will search for a `package.json` in the current folder and use the -`repository` property. +This command tries to guess at the likely location of a package's repository URL, and then tries to open it using the +[`--browser` config](/using-npm/config#browser) param. +If no package name is provided, it will search for a `package.json` in the current folder and use the `repository` property. ### Configuration diff --git a/docs/lib/content/commands/npm-restart.md b/docs/lib/content/commands/npm-restart.md index e1574ca18deca..a4d283c5fce1d 100644 --- a/docs/lib/content/commands/npm-restart.md +++ b/docs/lib/content/commands/npm-restart.md @@ -10,18 +10,16 @@ description: Restart a package ### Description -This restarts a project. It is equivalent to running `npm run -restart`. +This restarts a project. +It is equivalent to running `npm run restart`. -If the current project has a `"restart"` script specified in -`package.json`, then the following scripts will be run: +If the current project has a `"restart"` script specified in `package.json`, then the following scripts will be run: 1. prerestart 2. restart 3. postrestart -If it does _not_ have a `"restart"` script specified, but it does have -`stop` and/or `start` scripts, then the following scripts will be run: +If it does _not_ have a `"restart"` script specified, but it does have `stop` and/or `start` scripts, then the following scripts will be run: 1. prerestart 2. prestop diff --git a/docs/lib/content/commands/npm-root.md b/docs/lib/content/commands/npm-root.md index 60b77bb5a839c..48420f39dfe34 100644 --- a/docs/lib/content/commands/npm-root.md +++ b/docs/lib/content/commands/npm-root.md @@ -12,8 +12,8 @@ description: Display npm root Print the effective `node_modules` folder to standard out. -Useful for using npm in shell scripts that do things with the -`node_modules` folder. For example: +Useful for using npm in shell scripts that do things with the `node_modules` folder. +For example: ```bash #!/bin/bash diff --git a/docs/lib/content/commands/npm-run.md b/docs/lib/content/commands/npm-run.md index 9ed4e73aafa8f..cb73dd36c5e3d 100644 --- a/docs/lib/content/commands/npm-run.md +++ b/docs/lib/content/commands/npm-run.md @@ -10,16 +10,15 @@ description: Run arbitrary package scripts ### Description -This runs an arbitrary command from a package's `"scripts"` object. If no +This runs an arbitrary command from a package's `"scripts"` object. +If no `"command"` is provided, it will list the available scripts. -`run[-script]` is used by the test, start, restart, and stop commands, but -can be called directly, as well. When the scripts in the package are -printed out, they're separated into lifecycle (test, start, restart) and -directly-run scripts. +`run[-script]` is used by the test, start, restart, and stop commands, but can be called directly, as well. +When the scripts in the package are printed out, they're separated into lifecycle (test, start, restart) and directly-run scripts. -Any positional arguments are passed to the specified script. Use `--` to -pass `-`-prefixed flags and options which would otherwise be parsed by npm. +Any positional arguments are passed to the specified script. +Use `--` to pass `-`-prefixed flags and options which would otherwise be parsed by npm. For example: @@ -30,16 +29,13 @@ npm run test -- --grep="pattern" The arguments will only be passed to the script specified after `npm run` and not to any `pre` or `post` script. -The `env` script is a special built-in command that can be used to list -environment variables that will be available to the script at runtime. If an -"env" command is defined in your package, it will take precedence over the -built-in. +The `env` script is a special built-in command that can be used to list environment variables that will be available to the script at runtime. +If an +"env" command is defined in your package, it will take precedence over the built-in. -In addition to the shell's pre-existing `PATH`, `npm run` adds -`node_modules/.bin` to the `PATH` provided to scripts. Any binaries -provided by locally-installed dependencies can be used without the -`node_modules/.bin` prefix. For example, if there is a `devDependency` on -`tap` in your package, you should write: +In addition to the shell's pre-existing `PATH`, `npm run` adds `node_modules/.bin` to the `PATH` provided to scripts. +Any binaries provided by locally-installed dependencies can be used without the `node_modules/.bin` prefix. +For example, if there is a `devDependency` on `tap` in your package, you should write: ```bash "scripts": {"test": "tap test/*.js"} @@ -51,33 +47,25 @@ instead of "scripts": {"test": "node_modules/.bin/tap test/*.js"} ``` -The actual shell your script is run within is platform dependent. By default, -on Unix-like systems it is the `/bin/sh` command, on Windows it is -`cmd.exe`. +The actual shell your script is run within is platform dependent. +By default, +on Unix-like systems it is the `/bin/sh` command, on Windows it is `cmd.exe`. The actual shell referred to by `/bin/sh` also depends on the system. You can customize the shell with the [`script-shell` config](/using-npm/config#script-shell). -Scripts are run from the root of the package folder, regardless of what the -current working directory is when `npm run` is called. 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`. +Scripts are run from the root of the package folder, regardless of what the current working directory is when `npm run` is called. +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`. -`npm run` sets the `NODE` environment variable to the `node` executable -with which `npm` is executed. +`npm run` sets the `NODE` environment variable to the `node` executable with which `npm` is executed. -If you try to run a script without having a `node_modules` directory and it -fails, you will be given a warning to run `npm install`, just in case you've -forgotten. +If you try to run a script without having a `node_modules` directory and it fails, you will be given a warning to run `npm install`, just in case you've forgotten. ### Workspaces support You may use the [`workspace`](/using-npm/config#workspace) or -[`workspaces`](/using-npm/config#workspaces) configs in order to run an -arbitrary command from a package's `"scripts"` object in the context of the -specified workspaces. If no `"command"` is provided, it will list the available -scripts for each of these configured workspaces. +[`workspaces`](/using-npm/config#workspaces) configs in order to run an arbitrary command from a package's `"scripts"` object in the context of the specified workspaces. +If no `"command"` is provided, it will list the available scripts for each of these configured workspaces. Given a project with configured workspaces, e.g: @@ -93,8 +81,8 @@ Given a project with configured workspaces, e.g: `-- package.json ``` -Assuming the workspace configuration is properly set up at the root level -`package.json` file. e.g: +Assuming the workspace configuration is properly set up at the root level `package.json` file. +e.g: ``` { @@ -119,10 +107,8 @@ config along with a name or directory path: npm test --workspace=a ``` -The `workspace` config can also be specified multiple times in order to run a -specific script in the context of multiple workspaces. When defining values for -the `workspace` config in the command line, it also possible to use `-w` as a -shorthand, e.g: +The `workspace` config can also be specified multiple times in order to run a specific script in the context of multiple workspaces. +When defining values for the `workspace` config in the command line, it also possible to use `-w` as a shorthand, e.g: ``` npm test -w a -w b diff --git a/docs/lib/content/commands/npm-sbom.md b/docs/lib/content/commands/npm-sbom.md index a5ac81baf6704..ff1eaaa832d17 100644 --- a/docs/lib/content/commands/npm-sbom.md +++ b/docs/lib/content/commands/npm-sbom.md @@ -10,8 +10,8 @@ description: Generate a Software Bill of Materials (SBOM) ### Description -The `npm sbom` command generates a Software Bill of Materials (SBOM) listing the -dependencies for the current project. SBOMs can be generated in either +The `npm sbom` command generates a Software Bill of Materials (SBOM) listing the dependencies for the current project. +SBOMs can be generated in either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. ### Example CycloneDX SBOM @@ -206,10 +206,9 @@ dependencies for the current project. SBOMs can be generated in either ### Package lock only mode -If package-lock-only is enabled, only the information in the package -lock (or shrinkwrap) is loaded. This means that information from the -package.json files of your dependencies will not be included in the -result set (e.g. description, homepage, engines). +If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. +This means that information from the package.json files of your dependencies will not be included in the result set (e.g. +description, homepage, engines). ### Configuration diff --git a/docs/lib/content/commands/npm-search.md b/docs/lib/content/commands/npm-search.md index 52b66e93a6a0e..b5244df0d8117 100644 --- a/docs/lib/content/commands/npm-search.md +++ b/docs/lib/content/commands/npm-search.md @@ -10,26 +10,20 @@ description: Search for packages ### Description -Search the registry for packages matching the search terms. `npm search` -performs a linear, incremental, lexically-ordered search through package -metadata for all files in the registry. If your terminal has color -support, it will further highlight the matches in the results. This can -be disabled with the config item `color` - -Additionally, using the `--searchopts` and `--searchexclude` options -paired with more search terms will include and exclude further patterns. -The main difference between `--searchopts` and the standard search terms -is that the former does not highlight results in the output and you can -use them more fine-grained filtering. Additionally, you can add both of -these to your config to change default search filtering behavior. - -Search also allows targeting of maintainers in search results, by prefixing -their npm username with `=`. - -If a term starts with `/`, then it's interpreted as a regular expression -and supports standard JavaScript RegExp syntax. In this case search will -ignore a trailing `/` . (Note you must escape or quote many regular -expression characters in most shells.) +Search the registry for packages matching the search terms. +`npm search` +performs a linear, incremental, lexically-ordered search through package metadata for all files in the registry. +If your terminal has color support, it will further highlight the matches in the results. +This can be disabled with the config item `color` + +Additionally, using the `--searchopts` and `--searchexclude` options paired with more search terms will include and exclude further patterns. +The main difference between `--searchopts` and the standard search terms is that the former does not highlight results in the output and you can use them more fine-grained filtering. +Additionally, you can add both of these to your config to change default search filtering behavior. + +Search also allows targeting of maintainers in search results, by prefixing their npm username with `=`. + +If a term starts with `/`, then it's interpreted as a regular expression and supports standard JavaScript RegExp syntax. +In this case search will ignore a trailing `/` . (Note you must escape or quote many regular expression characters in most shells.) ### Configuration diff --git a/docs/lib/content/commands/npm-shrinkwrap.md b/docs/lib/content/commands/npm-shrinkwrap.md index dde762d40d43a..689f815891d7f 100644 --- a/docs/lib/content/commands/npm-shrinkwrap.md +++ b/docs/lib/content/commands/npm-shrinkwrap.md @@ -10,11 +10,9 @@ description: Lock down dependency versions for publication ### Description -This command repurposes `package-lock.json` into a publishable -`npm-shrinkwrap.json` or simply creates a new one. The file created and -updated by this command will then take precedence over any other existing -or future `package-lock.json` files. For a detailed explanation of the -design and purpose of package locks in npm, see +This command repurposes `package-lock.json` into a publishable `npm-shrinkwrap.json` or simply creates a new one. +The file created and updated by this command will then take precedence over any other existing or future `package-lock.json` files. +For a detailed explanation of the design and purpose of package locks in npm, see [package-lock-json](/configuring-npm/package-lock-json). ### See Also diff --git a/docs/lib/content/commands/npm-star.md b/docs/lib/content/commands/npm-star.md index 01d3a49d7e91f..7db44d809a17a 100644 --- a/docs/lib/content/commands/npm-star.md +++ b/docs/lib/content/commands/npm-star.md @@ -10,10 +10,12 @@ description: Mark your favorite packages ### Description -"Starring" a package means that you have some interest in it. It's +"Starring" a package means that you have some interest in it. +It's a vaguely positive way to show that you care. -It's a boolean thing. Starring repeatedly has no additional effect. +It's a boolean thing. +Starring repeatedly has no additional effect. ### More diff --git a/docs/lib/content/commands/npm-stars.md b/docs/lib/content/commands/npm-stars.md index 68f50815186b1..750b7bacff970 100644 --- a/docs/lib/content/commands/npm-stars.md +++ b/docs/lib/content/commands/npm-stars.md @@ -10,11 +10,9 @@ description: View packages marked as favorites ### Description -If you have starred a lot of neat things and want to find them again -quickly this command lets you do just that. +If you have starred a lot of neat things and want to find them again quickly this command lets you do just that. -You may also want to see your friend's favorite packages, in this case -you will most certainly enjoy this command. +You may also want to see your friend's favorite packages, in this case you will most certainly enjoy this command. ### Configuration diff --git a/docs/lib/content/commands/npm-start.md b/docs/lib/content/commands/npm-start.md index b3ab6cf2b745a..1cf690084bc12 100644 --- a/docs/lib/content/commands/npm-start.md +++ b/docs/lib/content/commands/npm-start.md @@ -13,15 +13,12 @@ description: Start a package This runs a predefined command specified in the `"start"` property of a package's `"scripts"` object. -If the `"scripts"` object does not define a `"start"` property, npm -will run `node server.js`. +If the `"scripts"` object does not define a `"start"` property, npm will run `node server.js`. -Note that this is different from the default node behavior of running -the file specified in a package's `"main"` attribute when evoking with -`node .` +Note that this is different from the default node behavior of running the file specified in a package's `"main"` attribute when evoking with `node .` -As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can -use custom arguments when executing scripts. Refer to [`npm run`](/commands/npm-run) for more details. +As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can use custom arguments when executing scripts. +Refer to [`npm run`](/commands/npm-run) for more details. ### Example diff --git a/docs/lib/content/commands/npm-stop.md b/docs/lib/content/commands/npm-stop.md index 05c9c556ac734..c2fb903296f10 100644 --- a/docs/lib/content/commands/npm-stop.md +++ b/docs/lib/content/commands/npm-stop.md @@ -10,11 +10,9 @@ description: Stop a package ### Description -This runs a predefined command specified in the "stop" property of a -package's "scripts" object. +This runs a predefined command specified in the "stop" property of a package's "scripts" object. -Unlike with [npm start](/commands/npm-start), there is no default script -that will run if the `"stop"` property is not defined. +Unlike with [npm start](/commands/npm-start), there is no default script that will run if the `"stop"` property is not defined. ### Example diff --git a/docs/lib/content/commands/npm-team.md b/docs/lib/content/commands/npm-team.md index d3b7ca58fe2af..65830bf43fe46 100644 --- a/docs/lib/content/commands/npm-team.md +++ b/docs/lib/content/commands/npm-team.md @@ -10,22 +10,18 @@ description: Manage organization teams and team memberships ### Description -Used to manage teams in organizations, and change team memberships. Does not -handle permissions for packages. +Used to manage teams in organizations, and change team memberships. +Does not handle permissions for packages. -Teams must always be fully qualified with the organization/scope they belong to -when operating on them, separated by a colon (`:`). That is, if you have a -`newteam` team in an `org` organization, you must always refer to that team -as `@org:newteam` in these commands. +Teams must always be fully qualified with the organization/scope they belong to when operating on them, separated by a colon (`:`). +That is, if you have a `newteam` team in an `org` organization, you must always refer to that team as `@org:newteam` in these commands. -If you have two-factor authentication enabled in `auth-and-writes` mode, then -you can provide a code from your authenticator with `[--otp ]`. -If you don't include this then you will be taken through a second factor flow based -on your `authtype`. +If you have two-factor authentication enabled in `auth-and-writes` mode, then you can provide a code from your authenticator with `[--otp ]`. +If you don't include this then you will be taken through a second factor flow based on your `authtype`. * create / destroy: - Create a new team, or destroy an existing one. Note: You cannot remove the - `developers` team, [learn more.](https://docs.npmjs.com/about-developers-team) + Create a new team, or destroy an existing one. + Note: You cannot remove the `developers` team, [learn more.](https://docs.npmjs.com/about-developers-team) Here's how to create a new team `newteam` under the `org` org: @@ -33,8 +29,7 @@ on your `authtype`. npm team create @org:newteam ``` - You should see a confirming message such as: `+@org:newteam` once the new - team has been created. + You should see a confirming message such as: `+@org:newteam` once the new team has been created. * add: Add a user to an existing team. @@ -50,8 +45,7 @@ on your `authtype`. * rm: Using `npm team rm` you can also remove users from a team they belong to. - Here's an example removing user `username` from `newteam` team - in `org` organization: + Here's an example removing user `username` from `newteam` team in `org` organization: ```bash npm team rm @org:newteam username @@ -61,9 +55,8 @@ on your `authtype`. `username removed from @org:newteam` * ls: - If performed on an organization name, will return a list of existing teams - under that organization. If performed on a team, it will instead return a list - of all users belonging to that particular team. + If performed on an organization name, will return a list of existing teams under that organization. + If performed on a team, it will instead return a list of all users belonging to that particular team. Here's an example of how to list all teams from an org named `org`: @@ -79,18 +72,14 @@ on your `authtype`. ### Details -`npm team` always operates directly on the current registry, configurable from -the command line using `--registry=`. +`npm team` always operates directly on the current registry, configurable from the command line using `--registry=`. -You must be a *team admin* to create teams and manage team membership, under -the given organization. Listing teams and team memberships may be done by -any member of the organization. +You must be a *team admin* to create teams and manage team membership, under the given organization. +Listing teams and team memberships may be done by any member of the organization. -Organization creation and management of team admins and *organization* members -is done through the website, not the npm CLI. +Organization creation and management of team admins and *organization* members is done through the website, not the npm CLI. -To use teams to manage permissions on packages belonging to your organization, -use the `npm access` command to grant or revoke the appropriate permissions. +To use teams to manage permissions on packages belonging to your organization, use the `npm access` command to grant or revoke the appropriate permissions. ### Configuration diff --git a/docs/lib/content/commands/npm-token.md b/docs/lib/content/commands/npm-token.md index a7df196285ea5..9fc763b82ddf4 100644 --- a/docs/lib/content/commands/npm-token.md +++ b/docs/lib/content/commands/npm-token.md @@ -13,8 +13,8 @@ description: Manage your authentication tokens This lets you list, create and revoke authentication tokens. * `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`. + Shows a table of all active authentication tokens. + You can request this as JSON with `--json` or tab-separated values with `--parseable`. ``` Read only token npm_1f… with id 7f3134 created 2017-10-21 @@ -27,29 +27,22 @@ Publish token npm_… with id e0cf92 created 2017-10-02 ``` * `npm token create [--read-only] [--cidr=]`: - 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. - - 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. + 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. + + 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. ``` Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d ``` * `npm token revoke `: - 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. + 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. ### Configuration diff --git a/docs/lib/content/commands/npm-undeprecate.md b/docs/lib/content/commands/npm-undeprecate.md index 076ac9eff2d0a..5647990a56940 100644 --- a/docs/lib/content/commands/npm-undeprecate.md +++ b/docs/lib/content/commands/npm-undeprecate.md @@ -10,11 +10,9 @@ description: Undeprecate a version of a package ### Description -This command will update the npm registry entry for a package, removing any -deprecation warnings that currently exist. +This command will update the npm registry entry for a package, removing any deprecation warnings that currently exist. -It works in the same way as [npm deprecate](/commands/npm-deprecate), except -that this command removes deprecation warnings instead of adding them. +It works in the same way as [npm deprecate](/commands/npm-deprecate), except that this command removes deprecation warnings instead of adding them. ### Configuration diff --git a/docs/lib/content/commands/npm-uninstall.md b/docs/lib/content/commands/npm-uninstall.md index 46e5af073e959..bf4b1694f22d6 100644 --- a/docs/lib/content/commands/npm-uninstall.md +++ b/docs/lib/content/commands/npm-uninstall.md @@ -10,23 +10,17 @@ description: Remove a package ### Description -This uninstalls a package, completely removing everything npm installed -on its behalf. +This uninstalls a package, completely removing everything npm installed on its behalf. It also removes the package from the `dependencies`, `devDependencies`, -`optionalDependencies`, and `peerDependencies` objects in your -`package.json`. +`optionalDependencies`, and `peerDependencies` objects in your `package.json`. -Further, if you have an `npm-shrinkwrap.json` or `package-lock.json`, npm -will update those files as well. +Further, if you have an `npm-shrinkwrap.json` or `package-lock.json`, npm will update those files as well. -`--no-save` will tell npm not to remove the package from your -`package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files. +`--no-save` will tell npm not to remove the package from your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files. -`--save` or `-S` will tell npm to remove the package from your -`package.json`, `npm-shrinkwrap.json`, and `package-lock.json` files. -This is the default, but you may need to use this if you have for -instance `save=false` in your `npmrc` file +`--save` or `-S` will tell npm to remove the package from your `package.json`, `npm-shrinkwrap.json`, and `package-lock.json` files. +This is the default, but you may need to use this if you have for instance `save=false` in your `npmrc` file In global mode (ie, with `-g` or `--global` appended to the command), it uninstalls the current package context as a global package. @@ -40,8 +34,7 @@ Scope is optional and follows the usual rules for [`scope`](/using-npm/scope). npm uninstall sax ``` -`sax` will no longer be in your `package.json`, `npm-shrinkwrap.json`, or -`package-lock.json` files. +`sax` will no longer be in your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files. ```bash npm uninstall lodash --no-save diff --git a/docs/lib/content/commands/npm-unpublish.md b/docs/lib/content/commands/npm-unpublish.md index 741fc83cee9aa..ce03ef15e408a 100644 --- a/docs/lib/content/commands/npm-unpublish.md +++ b/docs/lib/content/commands/npm-unpublish.md @@ -14,29 +14,23 @@ To learn more about how the npm registry treats unpublish, see our ### Warning Consider using the [`deprecate`](/commands/npm-deprecate) command instead, -if your intent is to encourage users to upgrade, or if you no longer -want to maintain a package. +if your intent is to encourage users to upgrade, or if you no longer want to maintain a package. ### Description -This removes a package version from the registry, deleting its entry and -removing the tarball. +This removes a package version from the registry, deleting its entry and removing the tarball. -The npm registry will return an error if you are not [logged -in](/commands/npm-adduser). +The npm registry will return an error if you are not [logged in](/commands/npm-adduser). -If you do not specify a package name at all, the name and version to be -unpublished will be pulled from the project in the current directory. +If you do not specify a package name at all, the name and version to be unpublished will be pulled from the project in the current directory. -If you specify a package name but do not specify a version or if you -remove all of a package's versions then the registry will remove the -root package entry entirely. +If you specify a package name but do not specify a version or if you remove all of a package's versions then the registry will remove the root package entry entirely. -Even if you unpublish a package version, that specific name and version -combination can never be reused. In order to publish the package again, -you must use a new version number. If you unpublish the entire package, -you may not publish any new versions of that package until 24 hours have -passed. +Even if you unpublish a package version, that specific name and version combination can never be reused. +In order to publish the package again, +you must use a new version number. +If you unpublish the entire package, +you may not publish any new versions of that package until 24 hours have passed. ### Configuration diff --git a/docs/lib/content/commands/npm-update.md b/docs/lib/content/commands/npm-update.md index 65919a4a7f914..0f453c1f72a8d 100644 --- a/docs/lib/content/commands/npm-update.md +++ b/docs/lib/content/commands/npm-update.md @@ -11,28 +11,22 @@ description: Update packages ### Description This command will update all the packages listed to the latest version -(specified by the [`tag` config](/using-npm/config#tag)), respecting the semver -constraints of both your package and its dependencies (if they also require the -same package). +(specified by the [`tag` config](/using-npm/config#tag)), respecting the semver constraints of both your package and its dependencies (if they also require the same package). It will also install missing packages. -If the `-g` flag is specified, this command will update globally installed -packages. +If the `-g` flag is specified, this command will update globally installed packages. -If no package name is specified, all packages in the specified location (global -or local) will be updated. +If no package name is specified, all packages in the specified location (global or local) will be updated. -Note that by default `npm update` will not update the semver values of direct -dependencies in your project `package.json`. If you want to also update -values in `package.json` you can run: `npm update --save` (or add the -`save=true` option to a [configuration file](/configuring-npm/npmrc) +Note that by default `npm update` will not update the semver values of direct dependencies in your project `package.json`. +If you want to also update values in `package.json` you can run: `npm update --save` (or add the `save=true` option to a [configuration file](/configuring-npm/npmrc) to make that the default behavior). ### Example -For the examples below, assume that the current package is `app` and it depends -on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` +For the examples below, assume that the current package is `app` and it depends on dependencies, `dep1` (`dep2`, .. etc.). +The published versions of `dep1` are: ```json @@ -75,9 +69,9 @@ However, if `app`'s `package.json` contains: } ``` -In this case, running `npm update` will install `dep1@1.1.2`. Even though the -`latest` tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is -equivalent to `>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies +In this case, running `npm update` will install `dep1@1.1.2`. +Even though the `latest` tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivalent to `>=1.1.1 <1.2.0`. +So the highest-sorting version that satisfies `~1.1.1` is used, which is `1.1.2`. #### Caret Dependencies below 1.0.0 @@ -100,8 +94,7 @@ If the dependence were on `^0.4.0`: } ``` -Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting -version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`) +Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`) #### Subdependencies @@ -129,26 +122,19 @@ and `dep2` itself depends on this limited range of `dep1` } ``` -Then `npm update` will install `dep1@1.1.2` because that is the highest -version that `dep2` allows. npm will prioritize having a single version -of `dep1` in your tree rather than two when that single version can -satisfy the semver requirements of multiple dependencies in your tree. -In this case if you really did need your package to use a newer version -you would need to use `npm install`. +Then `npm update` will install `dep1@1.1.2` because that is the highest version that `dep2` allows. + npm will prioritize having a single version of `dep1` in your tree rather than two when that single version can satisfy the semver requirements of multiple dependencies in your tree. +In this case if you really did need your package to use a newer version you would need to use `npm install`. #### Updating Globally-Installed Packages -`npm update -g` will apply the `update` action to each globally installed -package that is `outdated` -- that is, has a version that is different from -`wanted`. +`npm update -g` will apply the `update` action to each globally installed package that is `outdated` -- that is, has a version that is different from `wanted`. -Note: Globally installed packages are treated as if they are installed with a -caret semver range specified. So if you require to update to `latest` you may -need to run `npm install -g [...]` +Note: Globally installed packages are treated as if they are installed with a caret semver range specified. +So if you require to update to `latest` you may need to run `npm install -g [...]` -NOTE: If a package has been upgraded to a version newer than `latest`, it will -be _downgraded_. +NOTE: If a package has been upgraded to a version newer than `latest`, it will be _downgraded_. ### Configuration diff --git a/docs/lib/content/commands/npm-version.md b/docs/lib/content/commands/npm-version.md index a5167cd0dd3be..f9b5ed051567e 100644 --- a/docs/lib/content/commands/npm-version.md +++ b/docs/lib/content/commands/npm-version.md @@ -14,69 +14,57 @@ description: Bump a package version ### Description -Run this in a package directory to bump the version and write the new data -back to `package.json`, `package-lock.json`, and, if present, +Run this in a package directory to bump the version and write the new data back to `package.json`, `package-lock.json`, and, if present, `npm-shrinkwrap.json`. -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. +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. -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. +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. -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. If the -`message` config contains `%s` then that will be replaced with the resulting -version number. For example: +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. +If the `message` config contains `%s` then that will be replaced with the resulting version number. +For example: ```bash npm version patch -m "Upgrade to %s for reasons" ``` -If the [`sign-git-tag` config](/using-npm/config#sign-git-tag) is set, then the -tag will be signed using the `-s` flag to git. Note that you must have a default -GPG key set up in your git config for this to work properly. For example: +If the [`sign-git-tag` config](/using-npm/config#sign-git-tag) is set, then the tag will be signed using the `-s` flag to git. +Note that you must have a default GPG key set up in your git config for this to work properly. +For example: ```bash $ npm config set sign-git-tag true $ npm version patch -You need a passphrase to unlock the secret key for -user: "isaacs (http://blog.izs.me/) " +You need a passphrase to unlock the secret key for user: "isaacs (http://blog.izs.me/) " 2048-bit RSA key, ID 6C481CF6, created 2010-08-31 Enter passphrase: ``` -If `preversion`, `version`, or `postversion` are in the `scripts` property -of the package.json, they will be executed as part of running `npm -version`. +If `preversion`, `version`, or `postversion` are in the `scripts` property of the package.json, they will be executed as part of running `npm version`. The exact order of execution is as follows: -1. Check to make sure the git working directory is clean before we get - started. Your scripts may add files to the commit in future steps. +1. Check to make sure the git working directory is clean before we get started. + Your scripts may add files to the commit in future steps. This step is skipped if the `--force` flag is set. -2. Run the `preversion` script. These scripts have access to the old - `version` in package.json. A typical use would be running your full - test suite before deploying. Any files you want added to the commit - should be explicitly added using `git add`. -3. Bump `version` in `package.json` as requested (`patch`, `minor`, - `major`, etc). -4. Run the `version` script. These scripts have access to the new `version` - in package.json (so they can incorporate it into file headers in - generated files for example). Again, scripts should explicitly add - generated files to the commit using `git add`. +2. Run the `preversion` script. + These scripts have access to the old `version` in package.json. + A typical use would be running your full test suite before deploying. + Any files you want added to the commit should be explicitly added using `git add`. +3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc). +4. Run the `version` script. + These scripts have access to the new `version` in package.json (so they can incorporate it into file headers in generated files for example). + Again, scripts should explicitly add generated files to the commit using `git add`. 5. Commit and tag. -6. Run the `postversion` script. Use it to clean up the file system or - automatically push the commit and/or tag. +6. Run the `postversion` script. + Use it to clean up the file system or automatically push the commit and/or tag. Take the following example: @@ -90,10 +78,9 @@ Take the following example: } ``` -This runs all your tests and proceeds only if they pass. Then runs your -`build` script, and adds everything in the `dist` directory to the commit. -After the commit, it pushes the new commit and tag up to the server, and -deletes the `build/temp` directory. +This runs all your tests and proceeds only if they pass. +Then runs your `build` script, and adds everything in the `dist` directory to the commit. +After the commit, it pushes the new commit and tag up to the server, and deletes the `build/temp` directory. ### See Also diff --git a/docs/lib/content/commands/npm-view.md b/docs/lib/content/commands/npm-view.md index 63ff520e7bd29..5f82d55e3bdde 100644 --- a/docs/lib/content/commands/npm-view.md +++ b/docs/lib/content/commands/npm-view.md @@ -29,7 +29,8 @@ npm view ronn@0.3.5 dependencies ``` By default, `npm view` shows data about the current project context (by looking for a `package.json`). -To show field data for the current project use a file path (i.e. `.`): +To show field data for the current project use a file path (i.e. +`.`): ```bash npm view . dependencies @@ -42,25 +43,22 @@ To view the git repository URL for the latest version of `npm`, you would run th npm view npm repository.url ``` -This makes it easy to view information about a dependency with a bit of -shell scripting. For example, to view all the data about the version of -`opts` that `ronn` depends on, you could write the following: +This makes it easy to view information about a dependency with a bit of shell scripting. +For example, to view all the data about the version of `opts` that `ronn` depends on, you could write the following: ```bash npm view opts@$(npm view ronn dependencies.opts) ``` -For fields that are arrays, requesting a non-numeric field will return -all of the values from the objects in the list. For example, to get all -the contributor email addresses for the `express` package, you would run: +For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. +For example, to get all the contributor email addresses for the `express` package, you would run: ```bash npm view express contributors.email ``` -You may also use numeric indices in square braces to specifically select -an item in an array field. To just get the email address of the first -contributor in the list, you can run: +You may also use numeric indices in square braces to specifically select an item in an array field. +To just get the email address of the first contributor in the list, you can run: ```bash npm view express contributors[0].email @@ -73,31 +71,29 @@ npm view express time'[4.8.0]' ``` 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: +For example, to get all the contributor names and email addresses, you can do this: ```bash npm view express contributors.name contributors.email ``` -"Person" fields are shown as a string if they would be shown as an -object. So, for example, this will show the list of `npm` contributors in -the shortened string format. (See [`package.json`](/configuring-npm/package-json) for more on this.) +"Person" fields are shown as a string if they would be shown as an object. +So, for example, this will show the list of `npm` contributors in the shortened string format. + (See [`package.json`](/configuring-npm/package-json) for more on this.) ```bash npm view npm contributors ``` -If a version range is provided, then data will be printed for every -matching version of the package. This will show which version of `jsdom` +If a version range is provided, then data will be printed for every matching version of the package. +This will show which version of `jsdom` was required by each matching version of `yui3`: ```bash npm view yui3@'>0.5.4' dependencies.jsdom ``` -To show the `connect` package version history, you can do -this: +To show the `connect` package version history, you can do this: ```bash npm view connect versions @@ -109,17 +105,14 @@ npm view connect versions ### Output -If only a single string field for a single version is output, then it -will not be colorized or quoted, to enable piping the output to -another command. If the field is an object, it will be output as a JavaScript object literal. +If only a single string field for a single version is output, then it will not be colorized or quoted, to enable piping the output to another command. +If the field is an object, it will be output as a JavaScript object literal. If the `--json` flag is given, the outputted fields will be JSON. -If the version range matches multiple versions then each printed value -will be prefixed with the version it applies to. +If the version range matches multiple versions then each printed value will be prefixed with the version it applies to. -If multiple fields are requested, then each of them is prefixed with -the field name. +If multiple fields are requested, then each of them is prefixed with the field name. ### See Also diff --git a/docs/lib/content/commands/npm-whoami.md b/docs/lib/content/commands/npm-whoami.md index 99c787d62ef76..4f87e954761c2 100644 --- a/docs/lib/content/commands/npm-whoami.md +++ b/docs/lib/content/commands/npm-whoami.md @@ -12,12 +12,9 @@ description: Display npm username Display the npm username of the currently logged-in user. -If logged into a registry that provides token-based authentication, then -connect to the `/-/whoami` registry endpoint to find the username -associated with the token, and print to standard output. +If logged into a registry that provides token-based authentication, then connect to the `/-/whoami` registry endpoint to find the username associated with the token, and print to standard output. -If logged into a registry that uses Basic Auth, then simply print the -`username` portion of the authentication string. +If logged into a registry that uses Basic Auth, then simply print the `username` portion of the authentication string. ### Configuration diff --git a/docs/lib/content/commands/npm.md b/docs/lib/content/commands/npm.md index 16eda6968b8e6..9f5373e99da7d 100644 --- a/docs/lib/content/commands/npm.md +++ b/docs/lib/content/commands/npm.md @@ -14,123 +14,100 @@ description: javascript package manager ### Description -npm is the package manager for the Node JavaScript platform. It puts -modules in place so that node can find them, and manages dependency -conflicts intelligently. +npm is the package manager for the Node JavaScript platform. +It puts modules in place so that node can find them, and manages dependency conflicts intelligently. -It is extremely configurable to support a variety of use cases. Most -commonly, you use it to publish, discover, install, and develop node -programs. +It is extremely configurable to support a variety of use cases. +Most commonly, you use it to publish, discover, install, and develop node programs. Run `npm help` to get a list of available commands. ### Important -npm comes preconfigured to use npm's public registry at -https://registry.npmjs.org by default. Use of the npm public registry is -subject to terms of use available at -https://docs.npmjs.com/policies/terms. +npm comes preconfigured to use npm's public registry at https://registry.npmjs.org by default. +Use of the npm public registry is subject to terms of use available at https://docs.npmjs.com/policies/terms. -You can configure npm to use any compatible registry you like, and even -run your own registry. Use of someone else's registry is governed by -their terms of use. +You can configure npm to use any compatible registry you like, and even run your own registry. +Use of someone else's registry is governed by their terms of use. ### Introduction You probably got npm because you want to install stuff. -The very first thing you will most likely want to run in any node -program is `npm install` to install its dependencies. +The very first thing you will most likely want to run in any node program is `npm install` to install its dependencies. -You can also run `npm install blerg` to install the latest version of -"blerg". Check out [`npm install`](/commands/npm-install) for more -info. It can do a lot of stuff. +You can also run `npm install blerg` to install the latest version of "blerg". Check out [`npm install`](/commands/npm-install) for more info. +It can do a lot of stuff. -Use the `npm search` command to show everything that's available in the -public registry. Use `npm ls` to show everything you've installed. +Use the `npm search` command to show everything that's available in the public registry. +Use `npm ls` to show everything you've installed. ### Dependencies -If a package lists a dependency using a git URL, npm will install that -dependency using the [`git`](https://github.com/git-guides/install-git) -command and will generate an error if it is not installed. +If a package lists a dependency using a git URL, npm will install that dependency using the [`git`](https://github.com/git-guides/install-git) command and will generate an error if it is not installed. -If one of the packages npm tries to install is a native node module and -requires compiling of C++ Code, npm will use -[node-gyp](https://github.com/nodejs/node-gyp) for that task. -For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp) -needs Python, make and a buildchain like GCC. On Windows, -Python and Microsoft Visual Studio C++ are needed. For more information -visit [the node-gyp repository](https://github.com/nodejs/node-gyp) and -the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki). +If one of the packages npm tries to install is a native node module and requires compiling of C++ Code, npm will use [node-gyp](https://github.com/nodejs/node-gyp) for that task. +For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp) needs Python, make and a buildchain like GCC. On Windows, +Python and Microsoft Visual Studio C++ are needed. +For more information visit [the node-gyp repository](https://github.com/nodejs/node-gyp) and the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki). ### Directories -See [`folders`](/configuring-npm/folders) to learn about where npm puts -stuff. +See [`folders`](/configuring-npm/folders) to learn about where npm puts stuff. In particular, npm has two modes of operation: * local mode: - npm installs packages into the current project directory, which - defaults to the current working directory. Packages install to - `./node_modules`, and bins to `./node_modules/.bin`. + npm installs packages into the current project directory, which defaults to the current working directory. + Packages install to `./node_modules`, and bins to `./node_modules/.bin`. * global mode: - npm installs packages into the install prefix at - `$npm_config_prefix/lib/node_modules` and bins to - `$npm_config_prefix/bin`. + npm installs packages into the install prefix at `$npm_config_prefix/lib/node_modules` and bins to `$npm_config_prefix/bin`. -Local mode is the default. Use `-g` or `--global` on any command to -run in global mode instead. +Local mode is the default. +Use `-g` or `--global` on any command to run in global mode instead. ### Developer Usage -If you're using npm to develop and publish your code, check out the -following help topics: +If you're using npm to develop and publish your code, check out the following help topics: * json: - Make a package.json file. See - [`package.json`](/configuring-npm/package-json). + Make a package.json file. + See [`package.json`](/configuring-npm/package-json). * link: - Links your current working code into Node's path, so that you don't - have to reinstall every time you make a change. Use [`npm - link`](/commands/npm-link) to do this. + Links your current working code into Node's path, so that you don't have to reinstall every time you make a change. + Use [`npm link`](/commands/npm-link) to do this. * install: - It's a good idea to install things if you don't need the symbolic - link. Especially, installing other peoples code from the registry is - done via [`npm install`](/commands/npm-install) + It's a good idea to install things if you don't need the symbolic link. + Especially, installing other peoples code from the registry is done via [`npm install`](/commands/npm-install) * adduser: - Create an account or log in. When you do this, npm will store - credentials in the user config file. + Create an account or log in. + When you do this, npm will store credentials in the user config file. * publish: - Use the [`npm publish`](/commands/npm-publish) command to upload your - code to the registry. + Use the [`npm publish`](/commands/npm-publish) command to upload your code to the registry. #### Configuration -npm is extremely configurable. It reads its configuration options from -5 places. +npm is extremely configurable. +It reads its configuration options from 5 places. * Command line switches: - Set a config with `--key val`. All keys take a value, even if they - are booleans (the config parser doesn't know what the options are at - the time of parsing). If you do not provide a value (`--key`) then - the option is set to boolean `true`. + Set a config with `--key val`. + All keys take a value, even if they are booleans (the config parser doesn't know what the options are at the time of parsing). + If you do not provide a value (`--key`) then the option is set to boolean `true`. * Environment Variables: - Set any config by prefixing the name in an environment variable with - `npm_config_`. For example, `export npm_config_key=val`. + Set any config by prefixing the name in an environment variable with `npm_config_`. + For example, `export npm_config_key=val`. * User Configs: - The file at `$HOME/.npmrc` is an ini-formatted list of configs. If - present, it is parsed. If the `userconfig` option is set in the cli - or env, that file will be used instead. + The file at `$HOME/.npmrc` is an ini-formatted list of configs. + If present, it is parsed. + If the `userconfig` option is set in the cli or env, that file will be used instead. * Global Configs: - The file found at `./etc/npmrc` (relative to the global prefix will be - parsed if it is found. See [`npm prefix`](/commands/npm-prefix) for - more info on the global prefix. If the `globalconfig` option is set - in the cli, env, or user config, then that file is parsed instead. + The file found at `./etc/npmrc` (relative to the global prefix will be parsed if it is found. + See [`npm prefix`](/commands/npm-prefix) for more info on the global prefix. + If the `globalconfig` option is set in the cli, env, or user config, then that file is parsed instead. * Defaults: - npm's default configuration options are defined in - `lib/utils/config/definitions.js`. These must not be changed. + npm's default configuration options are defined in `lib/utils/config/definitions.js`. + These must not be changed. See [`config`](/using-npm/config) for much, much, more information. @@ -138,10 +115,7 @@ See [`config`](/using-npm/config) for much, much, more information. Patches welcome! -If you would like to help, but don't know what to work on, read the -[contributing -guidelines](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) and -check the issues list. +If you would like to help, but don't know what to work on, read the [contributing guidelines](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) and check the issues list. ### Bugs diff --git a/docs/lib/content/commands/npx.md b/docs/lib/content/commands/npx.md index 88ac18d7eba7c..eb0bbbb0de04a 100644 --- a/docs/lib/content/commands/npx.md +++ b/docs/lib/content/commands/npx.md @@ -11,31 +11,19 @@ description: Run a command from a local or remote npm package ### Description 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`. - -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. - -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`). - -Package names provided without a specifier will be matched with whatever -version exists in the local project. Package names with a specifier will -only be considered a match if they have the exact same name and version as -the local dependency. - -If no `-c` or `--call` option is provided, then the positional arguments -are used to generate the command string. If no `--package` options -are provided, then npm will attempt to determine the executable name from -the package specifier provided as the first positional argument according -to the following heuristic: +(either one installed locally, or fetched remotely), in a similar context as running it via `npm run`. + +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. + +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`). + +Package names provided without a specifier will be matched with whatever version exists in the local project. +Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency. + +If no `-c` or `--call` option is provided, then the positional arguments are used to generate the command string. +If no `--package` options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic: - If the package has a single entry in its `bin` field in `package.json`, or if all entries are aliases of the same command, then that command @@ -47,15 +35,13 @@ to the following heuristic: `npm exec` exits with an error. To run a binary _other than_ the named binary, specify one or more -`--package` options, which will prevent npm from inferring the package from -the first command argument. +`--package` options, which will prevent npm from inferring the package from the first command argument. ### `npx` vs `npm exec` -When run via the `npx` binary, all flags and options *must* be set prior to -any positional arguments. When run via `npm exec`, a double-hyphen `--` -flag can be used to suppress npm's parsing of switches and options that -should be sent to the executed command. +When run via the `npx` binary, all flags and options *must* be set prior to any positional arguments. +When run via `npm exec`, a double-hyphen `--` +flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command. For example: @@ -63,34 +49,30 @@ For example: $ npx foo@latest bar --package=@npmcli/foo ``` -In this case, npm will resolve the `foo` package name, and run the -following command: +In this case, npm will resolve the `foo` package name, and run the following command: ``` $ foo bar --package=@npmcli/foo ``` -Since the `--package` option comes _after_ the positional arguments, it is -treated as an argument to the executed command. +Since the `--package` option comes _after_ the positional arguments, it is treated as an argument to the executed command. -In contrast, due to npm's argument parsing logic, running this command is -different: +In contrast, due to npm's argument parsing logic, running this command is different: ``` $ npm exec foo@latest bar --package=@npmcli/foo ``` In this case, npm will parse the `--package` option first, resolving the -`@npmcli/foo` package. Then, it will execute the following command in that -context: +`@npmcli/foo` package. +Then, it will execute the following command in that context: ``` $ foo@latest bar ``` -The double-hyphen character is recommended to explicitly tell npm to stop -parsing command line options and switches. The following command would -thus be equivalent to the `npx` command above: +The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches. +The following command would thus be equivalent to the `npx` command above: ``` $ npm exec -- foo@latest bar --package=@npmcli/foo @@ -98,16 +80,14 @@ $ npm exec -- foo@latest bar --package=@npmcli/foo ### Examples -Run the version of `tap` in the local dependencies, with the provided -arguments: +Run the version of `tap` in the local dependencies, with the provided arguments: ``` $ npm exec -- tap --bail test/foo.js $ npx tap --bail test/foo.js ``` -Run a command _other than_ the command whose name matches the package name -by specifying a `--package` option: +Run a command _other than_ the command whose name matches the package name by specifying a `--package` option: ``` $ npm exec --package=foo -- bar --bar-argument @@ -125,27 +105,31 @@ $ npx -c 'eslint && say "hooray, lint passed"' ### Compatibility with Older npx Versions The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx` -package deprecated at that time. `npx` uses the `npm exec` -command instead of a separate argument parser and install process, with -some affordances to maintain backwards compatibility with the arguments it -accepted in previous versions. +package deprecated at that time. + `npx` uses the `npm exec` +command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions. This resulted in some shifts in its functionality: - Any `npm` config value may be provided. - To prevent security and user-experience problems from mistyping package - names, `npx` prompts before installing anything. Suppress this + names, `npx` prompts before installing anything. +Suppress this prompt with the `-y` or `--yes` option. - The `--no-install` option is deprecated, and will be converted to `--no`. - Shell fallback functionality is removed, as it is not advisable. - The `-p` argument is a shorthand for `--parseable` in npm, but shorthand - for `--package` in npx. This is maintained, but only for the `npx` + for `--package` in npx. +This is maintained, but only for the `npx` executable. -- The `--ignore-existing` option is removed. Locally installed bins are +- The `--ignore-existing` option is removed. +Locally installed bins are always present in the executed process `PATH`. -- The `--npm` option is removed. `npx` will always use the `npm` it ships +- The `--npm` option is removed. + `npx` will always use the `npm` it ships with. -- The `--node-arg` and `-n` options have been removed. Use [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) instead: e.g., +- The `--node-arg` and `-n` options have been removed. +Use [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) instead: e.g., `NODE_OPTIONS="--trace-warnings --trace-exit" npx foo --random=true` - The `--always-spawn` option is redundant, and thus removed. - The `--shell` option is replaced with `--script-shell`, but maintained diff --git a/docs/lib/content/configuring-npm/folders.md b/docs/lib/content/configuring-npm/folders.md index a9f0af220629c..56459c86930ba 100644 --- a/docs/lib/content/configuring-npm/folders.md +++ b/docs/lib/content/configuring-npm/folders.md @@ -6,60 +6,49 @@ description: Folder Structures Used by npm ### Description -npm puts various things on your computer. That's its job. +npm puts various things on your computer. +That's its job. This document will tell you what it puts where. #### tl;dr -* Local install (default): puts stuff in `./node_modules` of the current - package root. -* Global install (with `-g`): puts stuff in /usr/local or wherever node - is installed. +* Local install (default): puts stuff in `./node_modules` of the current package root. +* Global install (with `-g`): puts stuff in /usr/local or wherever node is installed. * Install it **locally** if you're going to `require()` it. * Install it **globally** if you're going to run it on the command line. * If you need both, then install it in both places, or use `npm link`. #### prefix Configuration -The [`prefix` config](/using-npm/config#prefix) defaults to the location where -node is installed. On most systems, this is `/usr/local`. On Windows, it's -`%AppData%\npm`. On Unix systems, it's one level up, since node is typically -installed at `{prefix}/bin/node` rather than `{prefix}/node.exe`. +The [`prefix` config](/using-npm/config#prefix) defaults to the location where node is installed. +On most systems, this is `/usr/local`. +On Windows, it's `%AppData%\npm`. +On Unix systems, it's one level up, since node is typically installed at `{prefix}/bin/node` rather than `{prefix}/node.exe`. When the `global` flag is set, npm installs things into this prefix. -When it is not set, it uses the root of the current package, or the -current working directory if not in a package already. +When it is not set, it uses the root of the current package, or the current working directory if not in a package already. #### Node Modules Packages are dropped into the `node_modules` folder under the `prefix`. -When installing locally, this means that you can -`require("packagename")` to load its main module, or -`require("packagename/lib/path/to/sub/module")` to load other modules. +When installing locally, this means that you can `require("packagename")` to load its main module, or `require("packagename/lib/path/to/sub/module")` to load other modules. Global installs on Unix systems go to `{prefix}/lib/node_modules`. -Global installs on Windows go to `{prefix}/node_modules` (that is, no -`lib` folder.) +Global installs on Windows go to `{prefix}/node_modules` (that is, no `lib` folder.) -Scoped packages are installed the same way, except they are grouped together -in a sub-folder of the relevant `node_modules` folder with the name of that -scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place -the package in `{prefix}/node_modules/@myorg/package`. See -[`scope`](/using-npm/scope) for more details. +Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant `node_modules` folder with the name of that scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place the package in `{prefix}/node_modules/@myorg/package`. +See [`scope`](/using-npm/scope) for more details. If you wish to `require()` a package, then install it locally. #### Executables -When in global mode, executables are linked into `{prefix}/bin` on Unix, -or directly into `{prefix}` on Windows. Ensure that path is in your -terminal's `PATH` environment to run them. +When in global mode, executables are linked into `{prefix}/bin` on Unix, or directly into `{prefix}` on Windows. +Ensure that path is in your terminal's `PATH` environment to run them. -When in local mode, executables are linked into -`./node_modules/.bin` so that they can be made available to scripts run -through npm. (For example, so that a test runner will be in the path -when you run `npm test`.) +When in local mode, executables are linked into `./node_modules/.bin` so that they can be made available to scripts run through npm. +(For example, so that a test runner will be in the path when you run `npm test`.) #### Man Pages @@ -71,67 +60,48 @@ Man pages are not installed on Windows systems. #### Cache -See [`npm cache`](/commands/npm-cache). Cache files are stored in `~/.npm` on Posix, or -`%LocalAppData%/npm-cache` on Windows. +See [`npm cache`](/commands/npm-cache). +Cache files are stored in `~/.npm` on Posix, or `%LocalAppData%/npm-cache` on Windows. This is controlled by the [`cache` config](/using-npm/config#cache) param. ### More Information -When installing locally, npm first tries to find an appropriate -`prefix` folder. This is so that `npm install foo@1.2.3` will install -to the sensible root of your package, even if you happen to have `cd`ed -into some other folder. +When installing locally, npm first tries to find an appropriate `prefix` folder. +This is so that `npm install foo@1.2.3` will install to the sensible root of your package, even if you happen to have `cd`ed into some other folder. -Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a `package.json` file, or a `node_modules` -folder. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands. (This -behavior is inspired by and similar to git's .git-folder seeking -logic when running git commands in a working dir.) +Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a `package.json` file, or a `node_modules` folder. +If such a thing is found, then that is treated as the effective "current directory" for the purpose of running npm commands. +(This behavior is inspired by and similar to git's .git-folder seeking logic when running git commands in a working dir.) If no package root is found, then the current folder is used. -When you run `npm install foo@1.2.3`, then the package is loaded into -the cache, and then unpacked into `./node_modules/foo`. Then, any of -foo's dependencies are similarly unpacked into -`./node_modules/foo/node_modules/...`. +When you run `npm install foo@1.2.3`, then the package is loaded into the cache, and then unpacked into `./node_modules/foo`. +Then, any of foo's dependencies are similarly unpacked into `./node_modules/foo/node_modules/...`. -Any bin files are symlinked to `./node_modules/.bin/`, so that they may -be found by npm scripts when necessary. +Any bin files are symlinked to `./node_modules/.bin/`, so that they may be found by npm scripts when necessary. #### Global Installation -If the [`global` config](/using-npm/config#global) is set to true, then npm will -install packages "globally". +If the [`global` config](/using-npm/config#global) is set to true, then npm will install packages "globally". -For global installation, packages are installed roughly the same way, -but using the folders described above. +For global installation, packages are installed roughly the same way, but using the folders described above. #### Cycles, Conflicts, and Folder Parsimony -Cycles are handled using the property of node's module system that it -walks up the directories looking for `node_modules` folders. So, at every -stage, if a package is already installed in an ancestor `node_modules` -folder, then it is not installed at the current location. - -Consider the case above, where `foo -> bar -> baz`. Imagine if, in -addition to that, baz depended on bar, so you'd have: -`foo -> bar -> baz -> bar -> baz ...`. However, since the folder -structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to -put another copy of bar into `.../baz/node_modules`, since when baz calls -`require("bar")`, it will get the copy that is installed in -`foo/node_modules/bar`. - -This shortcut is only used if the exact same -version would be installed in multiple nested `node_modules` folders. It -is still possible to have `a/node_modules/b/node_modules/a` if the two -"a" packages are different versions. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented. - -Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder (hoisting). +Cycles are handled using the property of node's module system that it walks up the directories looking for `node_modules` folders. +So, at every stage, if a package is already installed in an ancestor `node_modules` folder, then it is not installed at the current location. + +Consider the case above, where `foo -> bar -> baz`. +Imagine if, in addition to that, baz depended on bar, so you'd have: +`foo -> bar -> baz -> bar -> baz ...`. +However, since the folder structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to put another copy of bar into `.../baz/node_modules`, since when baz calls `require("bar")`, it will get the copy that is installed in `foo/node_modules/bar`. + +This shortcut is only used if the exact same version would be installed in multiple nested `node_modules` folders. +It is still possible to have `a/node_modules/b/node_modules/a` if the two "a" packages are different versions. +However, without repeating the exact same package multiple times, an infinite regress will always be prevented. + +Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder (hoisting). Since version 3, npm hoists dependencies by default. #### Example @@ -152,8 +122,7 @@ foo `-- bar ``` -In this case, we might expect a folder structure like this -(with all dependencies hoisted to the highest level possible): +In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible): ```bash foo @@ -167,36 +136,29 @@ foo +-- quux (3.2.0) <---[E] ``` -Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are -installed in foo's `node_modules` folder. +Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are installed in foo's `node_modules` folder. -Even though the latest copy of blerg is 1.3.7, foo has a specific -dependency on version 1.2.5. So, that gets installed at [A]. Since the -parent installation of blerg satisfies bar's dependency on `blerg@1.x`, -it does not install another copy under [B]. +Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. +So, that gets installed at [A]. +Since the parent installation of blerg satisfies bar's dependency on `blerg@1.x`, it does not install another copy under [B]. -Bar [B] also has dependencies on baz and asdf. Because it depends on `baz@2.x`, it cannot -re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D], -and must install its own copy [C]. In order to minimize duplication, npm hoists -dependencies to the top level by default, so asdf is installed under [A]. +Bar [B] also has dependencies on baz and asdf. +Because it depends on `baz@2.x`, it cannot re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D], and must install its own copy [C]. +In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under [A]. Underneath bar, the `baz -> quux -> bar` dependency creates a cycle. -However, because bar is already in quux's ancestry [B], it does not -unpack another copy of bar into that folder. Likewise, quux's [E] -folder tree is empty, because its dependency on bar is satisfied -by the parent folder copy installed at [B]. +However, because bar is already in quux's ancestry [B], it does not unpack another copy of bar into that folder. +Likewise, quux's [E] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at [B]. For a graphical breakdown of what is installed where, use `npm ls`. #### Publishing -Upon publishing, npm will look in the `node_modules` folder. If any of -the items there are not in the `bundleDependencies` array, then they will -not be included in the package tarball. +Upon publishing, npm will look in the `node_modules` folder. +If any of the items there are not in the `bundleDependencies` array, then they will not be included in the package tarball. -This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re-publish those items that -cannot be found elsewhere. See [`package.json`](/configuring-npm/package-json) for more information. +This allows a package maintainer to install all of their dependencies (and dev dependencies) locally, but only re-publish those items that cannot be found elsewhere. +See [`package.json`](/configuring-npm/package-json) for more information. ### See also diff --git a/docs/lib/content/configuring-npm/install.md b/docs/lib/content/configuring-npm/install.md index cee846745f218..f24a2915c7a54 100644 --- a/docs/lib/content/configuring-npm/install.md +++ b/docs/lib/content/configuring-npm/install.md @@ -6,13 +6,9 @@ description: Download and install node and npm ### Description -To publish and install packages to and from the public npm registry, you -must install Node.js and the npm command line interface using either a Node -version manager or a Node installer. **We strongly recommend using a Node -version manager to install Node.js and npm.** We do not recommend using a -Node installer, since the Node installation process installs npm in a -directory with local permissions and can cause permissions errors when you -run npm packages globally. +To publish and install packages to and from the public npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. +**We strongly recommend using a Node version manager to install Node.js and npm.** We do not recommend using a +Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally. ### Overview @@ -25,8 +21,7 @@ run npm packages globally. ### Checking your version of npm and Node.js -To see if you already have Node.js and npm installed and check the -installed version, run the following commands: +To see if you already have Node.js and npm installed and check the installed version, run the following commands: ``` node -v @@ -35,37 +30,32 @@ npm -v ### Using a Node version manager to install Node.js and npm -Node version managers allow you to install and switch between multiple -versions of Node.js and npm on your system so you can test your -applications on multiple versions of npm to ensure they work for users on -different versions. You can +Node version managers allow you to install and switch between multiple versions of Node.js and npm on your system so you can test your applications on multiple versions of npm to ensure they work for users on different versions. +You can [search for them on GitHub](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch). ### Using a Node installer to install Node.js and npm -If you are unable to use a Node version manager, you can use a Node -installer to install both Node.js and npm on your system. +If you are unable to use a Node version manager, you can use a Node installer to install both Node.js and npm on your system. * [Node.js installer](https://nodejs.org/en/download/) -* [NodeSource installer](https://github.com/nodesource/distributions). If +* [NodeSource installer](https://github.com/nodesource/distributions). +If you use Linux, we recommend that you use a NodeSource installer. #### macOS or Windows Node installers If you're using macOS or Windows, use one of the installers from the -[Node.js download page](https://nodejs.org/en/download/). Be sure to -install the version labeled **LTS**. Other versions have not yet been -tested with npm. +[Node.js download page](https://nodejs.org/en/download/). +Be sure to install the version labeled **LTS**. Other versions have not yet been tested with npm. #### Linux or other operating systems Node installers -If you're using Linux or another operating system, use one of the following -installers: +If you're using Linux or another operating system, use one of the following installers: - [NodeSource installer](https://github.com/nodesource/distributions) (recommended) - One of the installers on the [Node.js download page](https://nodejs.org/en/download/) -Or see [this page](https://nodejs.org/en/download/package-manager/) to -install npm for Linux in the way many Linux developers prefer. +Or see [this page](https://nodejs.org/en/download/package-manager/) to install npm for Linux in the way many Linux developers prefer. diff --git a/docs/lib/content/configuring-npm/npm-shrinkwrap-json.md b/docs/lib/content/configuring-npm/npm-shrinkwrap-json.md index ab0a241079380..f03998d641997 100644 --- a/docs/lib/content/configuring-npm/npm-shrinkwrap-json.md +++ b/docs/lib/content/configuring-npm/npm-shrinkwrap-json.md @@ -6,21 +6,14 @@ description: A publishable lockfile ### Description -`npm-shrinkwrap.json` is a file created by [`npm -shrinkwrap`](/commands/npm-shrinkwrap). It is identical to -`package-lock.json`, with one major caveat: Unlike `package-lock.json`, +`npm-shrinkwrap.json` is a file created by [`npm shrinkwrap`](/commands/npm-shrinkwrap). +It is identical to `package-lock.json`, with one major caveat: Unlike `package-lock.json`, `npm-shrinkwrap.json` may be included when publishing a package. -The recommended use-case for `npm-shrinkwrap.json` is applications deployed -through the publishing process on the registry: for example, daemons and -command-line tools intended as global installs or `devDependencies`. It's -strongly discouraged for library authors to publish this file, since that -would prevent end users from having control over transitive dependency -updates. +The recommended use-case for `npm-shrinkwrap.json` is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or `devDependencies`. +It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates. -If both `package-lock.json` and `npm-shrinkwrap.json` are present in a -package root, `npm-shrinkwrap.json` will be preferred over the -`package-lock.json` file. +If both `package-lock.json` and `npm-shrinkwrap.json` are present in a package root, `npm-shrinkwrap.json` will be preferred over the `package-lock.json` file. For full details and description of the `npm-shrinkwrap.json` file format, refer to the manual page for diff --git a/docs/lib/content/configuring-npm/npmrc.md b/docs/lib/content/configuring-npm/npmrc.md index eb1306e4c1003..77f094b6bb08d 100644 --- a/docs/lib/content/configuring-npm/npmrc.md +++ b/docs/lib/content/configuring-npm/npmrc.md @@ -9,8 +9,7 @@ description: The npm config files npm gets its config settings from the command line, environment variables, and `npmrc` files. -The `npm config` command can be used to update and edit the contents of the -user and global npmrc files. +The `npm config` command can be used to update and edit the contents of the user and global npmrc files. For a list of available configuration options, see [config](/using-npm/config). @@ -25,21 +24,21 @@ The four relevant files are: * npm builtin config file (`/path/to/npm/npmrc`) All npm config files are an ini-formatted list of `key = value` parameters. -Environment variables can be replaced using `${VARIABLE_NAME}`. By default -if the variable is not defined, it is left unreplaced. By adding `?` after -variable name they can be forced to evaluate to an empty string instead. For -example: +Environment variables can be replaced using `${VARIABLE_NAME}`. +By default if the variable is not defined, it is left unreplaced. +By adding `?` after variable name they can be forced to evaluate to an empty string instead. +For example: ```bash cache = ${HOME}/.npm-packages node-options = "${NODE_OPTIONS?} --use-system-ca" ``` -Each of these files is loaded, and config options are resolved in priority -order. For example, a setting in the userconfig file would override the -setting in the globalconfig file. +Each of these files is loaded, and config options are resolved in priority order. +For example, a setting in the userconfig file would override the setting in the globalconfig file. -Array values are specified by adding "[]" after the key name. For example: +Array values are specified by adding "[]" after the key name. +For example: ```bash key[] = "first value" @@ -49,7 +48,8 @@ key[] = "second value" #### Comments Lines in `.npmrc` files are interpreted as comments when they begin with a -`;` or `#` character. `.npmrc` files are parsed by +`;` or `#` character. +`.npmrc` files are parsed by [npm/ini](https://github.com/npm/ini), which specifies this comment syntax. For example: @@ -62,43 +62,37 @@ For example: #### Per-project config file -When working locally in a project, a `.npmrc` file in the root of the -project (ie, a sibling of `node_modules` and `package.json`) will set -config values specific to this project. +When working locally in a project, a `.npmrc` file in the root of the project (ie, a sibling of `node_modules` and `package.json`) will set config values specific to this project. -Note that this only applies to the root of the project that you're running -npm in. It has no effect when your module is published. For example, you -can't publish a module that forces itself to install globally, or in a -different location. +Note that this only applies to the root of the project that you're running npm in. +It has no effect when your module is published. +For example, you can't publish a module that forces itself to install globally, or in a different location. -Additionally, this file is not read in global mode, such as when running -`npm install -g`. +Additionally, this file is not read in global mode, such as when running `npm install -g`. #### Per-user config file -`$HOME/.npmrc` (or the `userconfig` param, if set in the environment or on -the command line) +`$HOME/.npmrc` (or the `userconfig` param, if set in the environment or on the command line) #### Global config file -`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): This file -is an ini-file formatted list of `key = value` parameters. Environment -variables can be replaced as above. +`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): This file is an ini-file formatted list of `key = value` parameters. +Environment variables can be replaced as above. #### Built-in config file `path/to/npm/itself/npmrc` -This is an unchangeable "builtin" configuration file that npm keeps -consistent across updates. Set fields in here using the `./configure` -script that comes with npm. This is primarily for distribution maintainers -to override default configs in a standard and consistent manner. +This is an unchangeable "builtin" configuration file that npm keeps consistent across updates. +Set fields in here using the `./configure` +script that comes with npm. +This is primarily for distribution maintainers to override default configs in a standard and consistent manner. ### Auth related configuration The settings `_auth`, `_authToken`, `username`, `_password`, `certfile`, -and `keyfile` must all be scoped to a specific registry. This ensures that -`npm` will never send credentials to the wrong host. +and `keyfile` must all be scoped to a specific registry. +This ensures that `npm` will never send credentials to the wrong host. The full list is: - `_auth` (base64 authentication string) @@ -112,8 +106,8 @@ The full list is: In order to scope these values, they must be prefixed by a URI fragment. If the credential is meant for any request to a registry on a single host, -the scope may look like `//registry.npmjs.org/:`. If it must be scoped to a -specific path on the host that path may also be provided, such as +the scope may look like `//registry.npmjs.org/:`. +If it must be scoped to a specific path on the host that path may also be provided, such as `//my-custom-registry.org/unique/path:`. ``` diff --git a/docs/lib/content/configuring-npm/package-json.md b/docs/lib/content/configuring-npm/package-json.md index e27a3c4b0efd9..018f28bf0474b 100644 --- a/docs/lib/content/configuring-npm/package-json.md +++ b/docs/lib/content/configuring-npm/package-json.md @@ -6,72 +6,64 @@ description: Specifics of npm's package.json handling ### Description -This document is all you need to know about what's required in your -package.json file. It must be actual JSON, not just a JavaScript object -literal. +This document is all you need to know about what's required in your package.json file. +It must be actual JSON, not just a JavaScript object literal. -A lot of the behavior described in this document is affected by the config -settings described in [`config`](/using-npm/config). +A lot of the behavior described in this document is affected by the config settings described in [`config`](/using-npm/config). ### name -If you plan to publish your package, the *most* important things in your -package.json are the name and version fields as they will be required. The -name and version together form an identifier that is assumed to be -completely unique. Changes to the package should come along with changes -to the version. If you don't plan to publish your package, the name and -version fields are optional. +If you plan to publish your package, the *most* important things in your package.json are the name and version fields as they will be required. +The name and version together form an identifier that is assumed to be completely unique. +Changes to the package should come along with changes to the version. +If you don't plan to publish your package, the name and version fields are optional. The name is what your thing is called. Some rules: -* The name must be less than or equal to 214 characters. This includes the - scope for scoped packages. -* The names of scoped packages can begin with a dot or an underscore. This - is not permitted without a scope. +* The name must be less than or equal to 214 characters. + This includes the scope for scoped packages. +* The names of scoped packages can begin with a dot or an underscore. + This is not permitted without a scope. * New packages must not have uppercase letters in the name. -* The name ends up being part of a URL, an argument on the command line, - and a folder name. Therefore, the name can't contain any non-URL-safe - characters. +* The name ends up being part of a URL, an argument on the command line, and a folder name. + Therefore, the name can't contain any non-URL-safe characters. Some tips: * Don't use the same name as a core Node module. -* Don't put "js" or "node" in the name. It's assumed that it's js, since - you're writing a package.json file, and you can specify the engine using - the "[engines](#engines)" field. (See below.) -* The name will probably be passed as an argument to require(), so it - should be something short, but also reasonably descriptive. -* You may want to check the npm registry to see if there's something by - that name already, before you get too attached to it. +* Don't put "js" or "node" in the name. + It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "[engines](#engines)" field. + (See below.) +* The name will probably be passed as an argument to require(), so it should be something short, but also reasonably descriptive. +* You may want to check the npm registry to see if there's something by that name already, before you get too attached to it. -A name can be optionally prefixed by a scope, e.g. `@npm/example`. See -[`scope`](/using-npm/scope) for more detail. +A name can be optionally prefixed by a scope, e.g. `@npm/example`. +See [`scope`](/using-npm/scope) for more detail. ### version -If you plan to publish your package, the *most* important things in your -package.json are the name and version fields as they will be required. The -name and version together form an identifier that is assumed to be -completely unique. Changes to the package should come along with changes -to the version. If you don't plan to publish your package, the name and -version fields are optional. +If you plan to publish your package, the *most* important things in your package.json are the name and version fields as they will be required. +The name and version together form an identifier that is assumed to be completely unique. +Changes to the package should come along with changes to the version. +If you don't plan to publish your package, the name and version fields are optional. -Version must be parseable by -[node-semver](https://github.com/npm/node-semver), which is bundled with -npm as a dependency. (`npm install semver` to use it yourself.) +Version must be parseable by [node-semver](https://github.com/npm/node-semver), which is bundled with npm as a dependency. +(`npm install semver` to use it yourself.) ### description -Put a description in it. It's a string. This helps people discover your -package, as it's listed in `npm search`. +Put a description in it. +It's a string. +This helps people discover your package, as it's listed in `npm search`. ### keywords -Put keywords in it. It's an array of strings. This helps people discover -your package as it's listed in `npm search`. +Put keywords in it. +It's an array of strings. +This helps people discover your package as it's listed in `npm search`. ### homepage @@ -85,9 +77,8 @@ Example: ### bugs -The URL to your project's issue tracker and / or the email address to which -issues should be reported. These are helpful for people who encounter -issues with your package. +The URL to your project's issue tracker and / or the email address to which issues should be reported. +These are helpful for people who encounter issues with your package. It should look like this: @@ -100,16 +91,15 @@ It should look like this: } ``` -You can specify either one or both values. If you want to provide only a -URL, you can specify the value for "bugs" as a simple string instead of an -object. +You can specify either one or both values. +If you want to provide only a +URL, you can specify the value for "bugs" as a simple string instead of an object. If a URL is provided, it will be used by the `npm bugs` command. ### license -You should specify a license for your package so that people know how they -are permitted to use it, and any restrictions you're placing on it. +You should specify a license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it. If you're using a common license such as BSD-2-Clause or MIT, add a current SPDX license identifier for the license you're using, like this: @@ -120,21 +110,17 @@ SPDX license identifier for the license you're using, like this: } ``` -You can check [the full list of SPDX license -IDs](https://spdx.org/licenses/). Ideally, you should pick one that is -[OSI](https://opensource.org/licenses/) approved. +You can check [the full list of SPDX license IDs](https://spdx.org/licenses/). +Ideally, you should pick one that is [OSI](https://opensource.org/licenses/) approved. -If your package is licensed under multiple common licenses, use an [SPDX -license expression syntax version 2.0 -string](https://spdx.dev/specifications/), like this: +If your package is licensed under multiple common licenses, use an [SPDX license expression syntax version 2.0 string](https://spdx.dev/specifications/), like this: ```json { "license" : "(ISC OR GPL-3.0)" } ``` -If you are using a license that hasn't been assigned an SPDX identifier, or if -you are using a custom license, use a string value like this one: +If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one: ```json { @@ -143,8 +129,7 @@ you are using a custom license, use a string value like this one: ``` Then include a file named `` at the top level of the package. -Some old packages used license objects or a "licenses" property containing -an array of license objects: +Some old packages used license objects or a "licenses" property containing an array of license objects: ```json // Not valid metadata @@ -170,7 +155,8 @@ an array of license objects: } ``` -Those styles are now deprecated. Instead, use SPDX expressions, like this: +Those styles are now deprecated. +Instead, use SPDX expressions, like this: ```json { @@ -184,8 +170,7 @@ Those styles are now deprecated. Instead, use SPDX expressions, like this: } ``` -Finally, if you do not wish to grant others the right to use a private or -unpublished package under any terms: +Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms: ```json { @@ -197,9 +182,9 @@ Consider also setting `"private": true` to prevent accidental publication. ### people fields: author, contributors -The "author" is one person. "contributors" is an array of people. A -"person" is an object with a "name" field and optionally "url" and "email", -like this: +The "author" is one person. +"contributors" is an array of people. +A "person" is an object with a "name" field and optionally "url" and "email", like this: ```json { @@ -209,8 +194,7 @@ like this: } ``` -Or you can shorten that all into a single string, and npm will parse it for -you: +Or you can shorten that all into a single string, and npm will parse it for you: ```json { @@ -224,9 +208,7 @@ npm also sets a top-level "maintainers" field with your npm user info. ### funding -You can specify an object containing a URL that provides up-to-date -information about ways to help fund development of your package, a -string URL, or an array of objects and string URLs: +You can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, a string URL, or an array of objects and string URLs: ```json { @@ -268,30 +250,22 @@ string URL, or an array of objects and string URLs: } ``` -Users can use the `npm fund` subcommand to list the `funding` URLs of all -dependencies of their project, direct and indirect. A shortcut to visit -each funding URL is also available when providing the project name such as: -`npm fund ` (when there are multiple URLs, the first one will -be visited) +Users can use the `npm fund` subcommand to list the `funding` URLs of all dependencies of their project, direct and indirect. +A shortcut to visit each funding URL is also available when providing the project name such as: +`npm fund ` (when there are multiple URLs, the first one will be visited) ### files -The optional `files` field is an array of file patterns that describes the -entries to be included when your package is installed as a dependency. File -patterns follow a similar syntax to `.gitignore`, but reversed: including a -file, directory, or glob pattern (`*`, `**/*`, and such) will make it so -that file is included in the tarball when it's packed. Omitting the field -will make it default to `["*"]`, which means it will include all files. +The optional `files` field is an array of file patterns that describes the entries to be included when your package is installed as a dependency. +File patterns follow a similar syntax to `.gitignore`, but reversed: including a file, directory, or glob pattern (`*`, `**/*`, and such) will make it so that file is included in the tarball when it's packed. +Omitting the field will make it default to `["*"]`, which means it will include all files. -Some special files and directories are also included or excluded regardless -of whether they exist in the `files` array (see below). +Some special files and directories are also included or excluded regardless of whether they exist in the `files` array (see below). -You can also provide a `.npmignore` file in the root of your package or in -subdirectories, which will keep files from being included. At the root of -your package it will not override the "files" field, but in subdirectories -it will. The `.npmignore` file works just like a `.gitignore`. If there is -a `.gitignore` file, and `.npmignore` is missing, `.gitignore`'s contents -will be used instead. +You can also provide a `.npmignore` file in the root of your package or in subdirectories, which will keep files from being included. +At the root of your package it will not override the "files" field, but in subdirectories it will. +The `.npmignore` file works just like a `.gitignore`. +If there is a `.gitignore` file, and `.npmignore` is missing, `.gitignore`'s contents will be used instead. Certain files are always included, regardless of settings: @@ -319,15 +293,13 @@ Some files are always ignored by default: * `config.gypi` * `node_modules` * `npm-debug.log` -* `package-lock.json` (use - [`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) - if you wish it to be published) +* `package-lock.json` (use [`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) if you wish it to be published) * `pnpm-lock.yaml` * `yarn.lock` * `bun.lockb` -Most of these ignored files can be included specifically if included in -the `files` globs. Exceptions to this are: +Most of these ignored files can be included specifically if included in the `files` globs. +Exceptions to this are: * `.git` * `.npmrc` @@ -341,44 +313,34 @@ These cannot be included. ### exports -The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. For more details see the [node.js documentation on package entry points](https://nodejs.org/api/packages.html#package-entry-points) +The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. +For more details see the [node.js documentation on package entry points](https://nodejs.org/api/packages.html#package-entry-points) ### main -The main field is a module ID that is the primary entry point to your -program. That is, if your package is named `foo`, and a user installs it, -and then does `require("foo")`, then your main module's exports object will -be returned. +The main field is a module ID that is the primary entry point to your program. +That is, if your package is named `foo`, and a user installs it, and then does `require("foo")`, then your main module's exports object will be returned. This should be a module relative to the root of your package folder. -For most modules, it makes the most sense to have a main script and often -not much else. +For most modules, it makes the most sense to have a main script and often not much else. If `main` is not set, it defaults to `index.js` in the package's root folder. ### browser -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`) +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`) ### bin -A lot of packages have one or more executable files that they'd like to -install into the PATH. npm makes this pretty easy (in fact, it uses this -feature to install the "npm" executable.) +A lot of packages have one or more executable files that they'd like to install into the PATH. npm makes this pretty easy (in fact, it uses this feature to install the "npm" executable.) -To use this, supply a `bin` field in your package.json which is a map of -command name to local file name. When this package is installed globally, -that file will be either linked inside the global bins directory or -a cmd (Windows Command File) will be created which executes the specified -file in the `bin` field, so it is available to run by `name` or `name.cmd` (on -Windows PowerShell). When this package is installed as a dependency in another -package, the file will be linked where it will be available to that package -either directly by `npm exec` or by name in other scripts when invoking them -via `npm run`. +To use this, supply a `bin` field in your package.json which is a map of command name to local file name. +When this package is installed globally, that file will be either linked inside the global bins directory or a cmd (Windows Command File) will be created which executes the specified file in the `bin` field, so it is available to run by `name` or `name.cmd` (on +Windows PowerShell). +When this package is installed as a dependency in another package, the file will be linked where it will be available to that package either directly by `npm exec` or by name in other scripts when invoking them via `npm run`. For example, myapp could have this: @@ -391,13 +353,10 @@ For example, myapp could have this: } ``` -So, when you install myapp, in case of unix-like OS it'll create a symlink -from the `cli.js` script to `/usr/local/bin/myapp` and in case of windows it -will create a cmd file usually at `C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd` -which runs the `cli.js` script. +So, when you install myapp, in case of unix-like OS it'll create a symlink from the `cli.js` script to `/usr/local/bin/myapp` and in case of windows it will create a cmd file usually at `C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd` which runs the `cli.js` script. -If you have a single executable, and its name should be the name of the -package, then you can just supply it as a string. For example: +If you have a single executable, and its name should be the name of the package, then you can just supply it as a string. +For example: ```json { @@ -419,23 +378,18 @@ would be the same as this: } ``` -Please make sure that your file(s) referenced in `bin` starts with -`#!/usr/bin/env node`; otherwise, the scripts are started without the node -executable! +Please make sure that your file(s) referenced in `bin` starts with `#!/usr/bin/env node`; otherwise, the scripts are started without the node executable! Note that you can also set the executable files using [directories.bin](#directoriesbin). -See [folders](/configuring-npm/folders#executables) for more info on -executables. +See [folders](/configuring-npm/folders#executables) for more info on executables. ### man -Specify either a single file or an array of filenames to put in place for -the `man` program to find. +Specify either a single file or an array of filenames to put in place for the `man` program to find. -If only a single file is provided, then it's installed such that it is the -result from `man `, regardless of its actual filename. For -example: +If only a single file is provided, then it's installed such that it is the result from `man `, regardless of its actual filename. +For example: ```json { @@ -447,8 +401,7 @@ example: } ``` -would link the `./man/doc.1` file in such that it is the target for `man -foo` +would link the `./man/doc.1` file in such that it is the target for `man foo` If the filename doesn't start with the package name, then it's prefixed. So, this: @@ -468,9 +421,8 @@ So, this: will create files to do `man foo` and `man foo-bar`. -Man files must end with a number, and optionally a `.gz` suffix if they are -compressed. The number dictates which man section the file is installed -into. +Man files must end with a number, and optionally a `.gz` suffix if they are compressed. +The number dictates which man section the file is installed into. ```json { @@ -489,34 +441,28 @@ will create entries for `man foo` and `man 2 foo` ### directories -The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec -details a few ways that you can indicate the structure of your package -using a `directories` object. If you look at [npm's -package.json](https://registry.npmjs.org/npm/latest), you'll see that it -has directories for doc, lib, and man. +The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a few ways that you can indicate the structure of your package using a `directories` object. +If you look at [npm's package.json](https://registry.npmjs.org/npm/latest), you'll see that it has directories for doc, lib, and man. In the future, this information may be used in other creative ways. #### directories.bin -If you specify a `bin` directory in `directories.bin`, all the files in -that folder will be added. +If you specify a `bin` directory in `directories.bin`, all the files in that folder will be added. -Because of the way the `bin` directive works, specifying both a `bin` path -and setting `directories.bin` is an error. If you want to specify -individual files, use `bin`, and for all the files in an existing `bin` -directory, use `directories.bin`. +Because of the way the `bin` directive works, specifying both a `bin` path and setting `directories.bin` is an error. +If you want to specify individual files, use `bin`, and for all the files in an existing `bin` directory, use `directories.bin`. #### directories.man -A folder that is full of man pages. Sugar to generate a "man" array by -walking the folder. +A folder that is full of man pages. +Sugar to generate a "man" array by walking the folder. ### repository -Specify the place where your code lives. This is helpful for people who -want to contribute. If the git repo is on GitHub, then the `npm repo` -command will be able to find you. +Specify the place where your code lives. +This is helpful for people who want to contribute. +If the git repo is on GitHub, then the `npm repo` command will be able to find you. Do it like this: @@ -529,13 +475,11 @@ Do it like this: } ``` -The URL should be a publicly available (perhaps read-only) URL that can be -handed directly to a VCS program without any modification. It should not -be a URL to an html project page that you put in your browser. It's for -computers. +The URL should be a publicly available (perhaps read-only) URL that can be handed directly to a VCS program without any modification. +It should not be a URL to an html project page that you put in your browser. +It's for computers. -For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the -same shortcut syntax you use for `npm install`: +For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same shortcut syntax you use for `npm install`: ```json { @@ -551,9 +495,7 @@ same shortcut syntax you use for `npm install`: } ``` -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: +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: ```json { @@ -567,18 +509,15 @@ which it lives: ### scripts -The "scripts" property is a dictionary containing script commands that are -run at various times in the lifecycle of your package. The key is the -lifecycle event, and the value is the command to run at that point. +The "scripts" property is a dictionary containing script commands that are run at various times in the lifecycle of your package. +The key is the lifecycle event, and the value is the command to run at that point. -See [`scripts`](/using-npm/scripts) to find out more about writing package -scripts. +See [`scripts`](/using-npm/scripts) to find out more about writing package scripts. ### config -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: +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: ```json { @@ -589,18 +528,16 @@ had the following: } ``` -It could also have a "start" script that referenced the -`npm_package_config_port` environment variable. +It could also have a "start" script that referenced the `npm_package_config_port` environment variable. ### dependencies -Dependencies are specified in a simple object that maps a package name to a -version range. The version range is a string which has one or more -space-separated descriptors. Dependencies can also be identified with a -tarball or git URL. +Dependencies are specified in a simple object that maps a package name to a version range. +The version range is a string which has one or more space-separated descriptors. +Dependencies can also be identified with a tarball or git URL. -**Please do not put test harnesses or transpilers or other "development" -time tools in your `dependencies` object.** See `devDependencies`, below. +**Please do not put test harnesses or transpilers or other "development" time tools in your `dependencies` object.** +See `devDependencies`, below. See [semver](https://github.com/npm/node-semver#versions) for more details about specifying version ranges. @@ -609,8 +546,7 @@ See [semver](https://github.com/npm/node-semver#versions) for more details about * `>=version` etc * `://[[:]@][:][:][/][# | #semver:] ``` -`` is one of `git`, `git+ssh`, `git+http`, `git+https`, or -`git+file`. +`` is one of `git`, `git+ssh`, `git+http`, `git+https`, or `git+file`. -If `#` is provided, it will be used to clone exactly that -commit. If the commit-ish has the format `#semver:`, `` can -be any valid semver range or exact version, and npm will look for any tags -or refs matching that range in the remote repository, much as it would for -a registry dependency. If neither `#` or `#semver:` is -specified, then the default branch is used. +If `#` is provided, it will be used to clone exactly that commit. +If the commit-ish has the format `#semver:`, `` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. +If neither `#` or `#semver:` is specified, then the default branch is used. Examples: @@ -681,14 +611,10 @@ git+https://isaacs@github.com/npm/cli.git git://github.com/npm/cli.git#v1.0.27 ``` -When installing from a `git` repository, the presence of certain fields in the -`package.json` will cause npm to believe it needs to perform a build. To do so -your repository will be cloned into a temporary directory, all of its deps -installed, relevant scripts run, and the resulting directory packed and -installed. +When installing from a `git` repository, the presence of certain fields in the `package.json` will cause npm to believe it needs to perform a build. +To do so your repository will be cloned into a temporary directory, all of its deps installed, relevant scripts run, and the resulting directory packed and installed. -This flow will occur if your git dependency uses `workspaces`, or if any of the -following scripts are present: +This flow will occur if your git dependency uses `workspaces`, or if any of the following scripts are present: * `build` * `prepare` @@ -697,15 +623,13 @@ following scripts are present: * `install` * `postinstall` -If your git repository includes pre-built artifacts, you will likely want to -make sure that none of the above scripts are defined, or your dependency -will be rebuilt for every installation. +If your git repository includes pre-built artifacts, you will likely want to make sure that none of the above scripts are defined, or your dependency will be rebuilt for every installation. #### GitHub URLs As of version 1.1.65, you can refer to GitHub URLs as just "foo": -"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be -included. For example: +"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be included. +For example: ```json { @@ -721,9 +645,8 @@ included. For example: #### Local Paths -As of version 2.0.0 you can provide a path to a local directory that -contains a package. Local paths can be saved using `npm install -S` or `npm -install --save`, using any of these forms: +As of version 2.0.0 you can provide a path to a local directory that contains a package. +Local paths can be saved using `npm install -S` or `npm install --save`, using any of these forms: ```bash ../foo/bar @@ -732,8 +655,8 @@ install --save`, using any of these forms: /foo/bar ``` -in which case they will be normalized to a relative path and added to your -`package.json`. For example: +in which case they will be normalized to a relative path and added to your `package.json`. +For example: ```json { @@ -744,30 +667,22 @@ in which case they will be normalized to a relative path and added to your } ``` -This feature is helpful for local offline development and creating tests -that require npm installing where you don't want to hit an external server, -but should not be used when publishing your package to the public registry. +This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing your package to the public registry. -*note*: Packages linked by local path will not have their own -dependencies installed when `npm install` is run. You must -run `npm install` from inside the local path itself. +*note*: Packages linked by local path will not have their own dependencies installed when `npm install` is run. +You must run `npm install` from inside the local path itself. ### devDependencies -If someone is planning on downloading and using your module in their -program, then they probably don't want or need to download and build the -external test or documentation framework that you use. +If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use. -In this case, it's best to map these additional items in a -`devDependencies` object. +In this case, it's best to map these additional items in a `devDependencies` object. -These things will be installed when doing `npm link` or `npm install` from -the root of a package, and can be managed like any other npm configuration -param. See [`config`](/using-npm/config) for more on the topic. +These things will be installed when doing `npm link` or `npm install` from the root of a package, and can be managed like any other npm configuration param. +See [`config`](/using-npm/config) for more on the topic. For build steps that are not platform-specific, such as compiling -CoffeeScript or other languages to JavaScript, use the `prepare` script to -do this, and make the required package a devDependency. +CoffeeScript or other languages to JavaScript, use the `prepare` script to do this, and make the required package a devDependency. For example: @@ -786,18 +701,13 @@ For example: } ``` -The `prepare` script will be run before publishing, so that users can -consume the functionality without requiring them to compile it themselves. -In dev mode (ie, locally running `npm install`), it'll run this script as -well, so that you can test it easily. +The `prepare` script will be run before publishing, so that users can consume the functionality without requiring them to compile it themselves. +In dev mode (ie, locally running `npm install`), it'll run this script as well, so that you can test it easily. ### peerDependencies -In some cases, you want to express the compatibility of your package with a -host tool or library, while not necessarily doing a `require` of this host. -This is usually referred to as a *plugin*. Notably, your module may be -exposing a specific interface, expected and specified by the host -documentation. +In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a `require` of this host. +This is usually referred to as a *plugin*. Notably, your module may be exposing a specific interface, expected and specified by the host documentation. For example: @@ -811,39 +721,30 @@ For example: } ``` -This ensures your package `@npm/tea-latte` can be installed *along* with the -second major version of the host package `@npm/tea` only. `npm install -tea-latte` could possibly yield the following dependency graph: +This ensures your package `@npm/tea-latte` can be installed *along* with the second major version of the host package `@npm/tea` only. +`npm install tea-latte` could possibly yield the following dependency graph: ```bash ├── @npm/tea-latte@1.3.5 └── @npm/tea@2.2.0 ``` -In npm versions 3 through 6, `peerDependencies` were not automatically -installed, and would raise a warning if an invalid version of the peer -dependency was found in the tree. As of npm v7, peerDependencies _are_ -installed by default. +In npm versions 3 through 6, `peerDependencies` were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree. +As of npm v7, peerDependencies _are_ installed by default. -Trying to install another plugin with a conflicting requirement may cause -an error if the tree cannot be resolved correctly. For this reason, make -sure your plugin requirement is as broad as possible, and not to lock it -down to specific patch versions. +Trying to install another plugin with a conflicting requirement may cause an error if the tree cannot be resolved correctly. +For this reason, make sure your plugin requirement is as broad as possible, and not to lock it down to specific patch versions. -Assuming the host complies with [semver](https://semver.org/), only changes -in the host package's major version will break your plugin. Thus, if you've -worked with every 1.x version of the host package, use `"^1.0"` or `"1.x"` -to express this. If you depend on features introduced in 1.5.2, use -`"^1.5.2"`. +Assuming the host complies with [semver](https://semver.org/), only changes in the host package's major version will break your plugin. +Thus, if you've worked with every 1.x version of the host package, use `"^1.0"` or `"1.x"` to express this. +If you depend on features introduced in 1.5.2, use `"^1.5.2"`. ### peerDependenciesMeta -The `peerDependenciesMeta` field serves to provide npm more information on how -your peer dependencies are to be used. Specifically, it allows peer -dependencies to be marked as optional. Npm will not automatically install -optional peer dependencies. This allows you to -integrate and interact with a variety of host packages without requiring -all of them to be installed. +The `peerDependenciesMeta` field serves to provide npm more information on how your peer dependencies are to be used. +Specifically, it allows peer dependencies to be marked as optional. +Npm will not automatically install optional peer dependencies. +This allows you to integrate and interact with a variety of host packages without requiring all of them to be installed. For example: @@ -865,13 +766,9 @@ For example: ### bundleDependencies -This defines an array of package names that will be bundled when publishing -the package. +This defines an array of package names that will be bundled when publishing the package. -In cases where you need to preserve npm packages locally or have them -available through a single file download, you can bundle the packages in a -tarball file by specifying the package names in the `bundleDependencies` -array and executing `npm pack`. +In cases where you need to preserve npm packages locally or have them available through a single file download, you can bundle the packages in a tarball file by specifying the package names in the `bundleDependencies` array and executing `npm pack`. For example: @@ -889,28 +786,24 @@ If we define a package.json like this: ``` we can obtain `@npm/awesome-web-framework-1.0.0.tgz` file by running `npm pack`. -This file contains the dependencies `@npm/renderized` and `@npm/super-streams` which -can be installed in a new project by executing `npm install -awesome-web-framework-1.0.0.tgz`. Note that the package names do not -include any versions, as that information is specified in `dependencies`. +This file contains the dependencies `@npm/renderized` and `@npm/super-streams` which can be installed in a new project by executing `npm install awesome-web-framework-1.0.0.tgz`. +Note that the package names do not include any versions, as that information is specified in `dependencies`. If this is spelled `"bundledDependencies"`, then that is also honored. -Alternatively, `"bundleDependencies"` can be defined as a boolean value. A -value of `true` will bundle all dependencies, a value of `false` will bundle -none. +Alternatively, `"bundleDependencies"` can be defined as a boolean value. +A value of `true` will bundle all dependencies, a value of `false` will bundle none. ### optionalDependencies -If a dependency can be used, but you would like npm to proceed if it cannot -be found or fails to install, then you may put it in the -`optionalDependencies` object. This is a map of package name to version or -URL, just like the `dependencies` object. The difference is that build -failures do not cause installation to fail. Running `npm install ---omit=optional` will prevent these dependencies from being installed. +If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the `optionalDependencies` object. +This is a map of package name to version or +URL, just like the `dependencies` object. +The difference is that build failures do not cause installation to fail. +Running `npm install --omit=optional` will prevent these dependencies from being installed. -It is still your program's responsibility to handle the lack of the -dependency. For example, something like this: +It is still your program's responsibility to handle the lack of the dependency. +For example, something like this: ```js try { @@ -930,29 +823,20 @@ if (foo) { } ``` -Entries in `optionalDependencies` will override entries of the same name in -`dependencies`, so it's usually best to only put in one place. +Entries in `optionalDependencies` will override entries of the same name in `dependencies`, so it's usually best to only put in one place. ### overrides -If you need to make specific changes to dependencies of your dependencies, for -example replacing the version of a dependency with a known security issue, -replacing an existing dependency with a fork, or making sure that the same -version of a package is used everywhere, then you may add an override. +If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override. -Overrides provide a way to replace a package in your dependency tree with -another version, or another package entirely. These changes can be scoped as -specific or as vague as desired. +Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. +These changes can be scoped as specific or as vague as desired. Overrides are only considered in the root `package.json` file for a project. -Overrides in installed dependencies (including -[workspaces](/using-npm/workspaces)) are not considered in dependency tree -resolution. Published packages may dictate their resolutions by pinning -dependencies or using an -[`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) file. +Overrides in installed dependencies (including [workspaces](/using-npm/workspaces)) are not considered in dependency tree resolution. +Published packages may dictate their resolutions by pinning dependencies or using an [`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) file. -To make sure the package `@npm/foo` is always installed as version `1.0.0` no matter -what version your dependencies rely on: +To make sure the package `@npm/foo` is always installed as version `1.0.0` no matter what version your dependencies rely on: ```json { @@ -962,10 +846,8 @@ what version your dependencies rely on: } ``` -The above is a short hand notation, the full object form can be used to allow -overriding a package itself as well as a child of the package. This will cause -`@npm/foo` to always be `1.0.0` while also making `@npm/bar` at any depth beyond `@npm/foo` -also `1.0.0`: +The above is a short hand notation, the full object form can be used to allow overriding a package itself as well as a child of the package. +This will cause `@npm/foo` to always be `1.0.0` while also making `@npm/bar` at any depth beyond `@npm/foo` also `1.0.0`: ```json { @@ -978,8 +860,7 @@ also `1.0.0`: } ``` -To only override `@npm/foo` to be `1.0.0` when it's a child (or grandchild, or great -grandchild, etc) of the package `@npm/bar`: +To only override `@npm/foo` to be `1.0.0` when it's a child (or grandchild, or great grandchild, etc) of the package `@npm/bar`: ```json { @@ -991,8 +872,8 @@ grandchild, etc) of the package `@npm/bar`: } ``` -Keys can be nested to any arbitrary length. To override `@npm/foo` only when it's a -child of `@npm/bar` and only when `@npm/bar` is a child of `@npm/baz`: +Keys can be nested to any arbitrary length. +To override `@npm/foo` only when it's a child of `@npm/bar` and only when `@npm/bar` is a child of `@npm/baz`: ```json { @@ -1019,11 +900,8 @@ To override `@npm/foo` to `1.0.0`, but only when it's a child of `@npm/bar@2.0.0 } ``` -You may not set an override for a package that you directly depend on unless -both the dependency and the override itself share the exact same spec. To make -this limitation easier to deal with, overrides may also be defined as a -reference to a spec for a direct dependency by prefixing the name of the -package you wish the version to match with a `$`. +You may not set an override for a package that you directly depend on unless both the dependency and the override itself share the exact same spec. +To make this limitation easier to deal with, overrides may also be defined as a reference to a spec for a direct dependency by prefixing the name of the package you wish the version to match with a `$`. ```json { @@ -1055,11 +933,10 @@ You can specify the version of node that your stuff works on: } ``` -And, like with dependencies, if you don't specify the version (or if you -specify "\*" as the version), then any version of node will do. +And, like with dependencies, if you don't specify the version (or if you specify "\*" as the version), then any version of node will do. -You can also use the "engines" field to specify which versions of npm are -capable of properly installing your program. For example: +You can also use the "engines" field to specify which versions of npm are capable of properly installing your program. +For example: ```json { @@ -1069,15 +946,11 @@ capable of properly installing your program. For example: } ``` -Unless the user has set the -[`engine-strict` config](/using-npm/config#engine-strict) flag, this field is -advisory only and will only produce warnings when your package is installed as a -dependency. +Unless the user has set the [`engine-strict` config](/using-npm/config#engine-strict) flag, this field is advisory only and will only produce warnings when your package is installed as a dependency. ### os -You can specify which operating systems your -module will run on: +You can specify which operating systems your module will run on: ```json { @@ -1088,8 +961,7 @@ module will run on: } ``` -You can also block instead of allowing operating systems, just prepend the -blocked os with a '!': +You can also block instead of allowing operating systems, just prepend the blocked os with a '!': ```json { @@ -1101,13 +973,11 @@ blocked os with a '!': The host operating system is determined by `process.platform` -It is allowed to both block and allow an item, although there isn't any -good reason to do this. +It is allowed to both block and allow an item, although there isn't any good reason to do this. ### cpu -If your code only runs on certain cpu architectures, -you can specify which ones. +If your code only runs on certain cpu architectures, you can specify which ones. ```json { @@ -1133,8 +1003,8 @@ The host architecture is determined by `process.arch` ### libc -If your code only runs or builds in certain versions of libc, you can -specify which ones. This field only applies if `os` is `linux`. +If your code only runs or builds in certain versions of libc, you can specify which ones. +This field only applies if `os` is `linux`. ```json { @@ -1147,12 +1017,20 @@ specify which ones. This field only applies if `os` is `linux`. The `devEngines` field aids engineers working on a codebase to all be using the same tooling. -You can specify a `devEngines` property in your `package.json` which will run before `install`, `ci`, and `run` commands. +You can specify a `devEngines` property in your `package.json` which will run before `install`, `ci`, and `run` commands. + -> Note: `engines` and `devEngines` differ in object shape. They also function very differently. `engines` is designed to alert the user when a dependency uses a different npm or node version than the project it's being used in, whereas `devEngines` is used to alert people interacting with the source code of a project. +> Note: `engines` and `devEngines` differ in object shape. +They also function very differently. +`engines` is designed to alert the user when a dependency uses a different npm or node version than the project it's being used in, whereas `devEngines` is used to alert people interacting with the source code of a project. -The supported keys under the `devEngines` property are `cpu`, `os`, `libc`, `runtime`, and `packageManager`. Each property can be an object or an array of objects. Objects must contain `name`, and optionally can specify `version`, and `onFail`. `onFail` can be `warn`, `error`, or `ignore`, and if left undefined is of the same value as `error`. `npm` will assume that you're running with `node`. -Here's an example of a project that will fail if the environment is not `node` and `npm`. If you set `runtime.name` or `packageManager.name` to any other string, it will fail within the npm CLI. +The supported keys under the `devEngines` property are `cpu`, `os`, `libc`, `runtime`, and `packageManager`. +Each property can be an object or an array of objects. +Objects must contain `name`, and optionally can specify `version`, and `onFail`. +`onFail` can be `warn`, `error`, or `ignore`, and if left undefined is of the same value as `error`. +`npm` will assume that you're running with `node`. +Here's an example of a project that will fail if the environment is not `node` and `npm`. +If you set `runtime.name` or `packageManager.name` to any other string, it will fail within the npm CLI. ```json { @@ -1171,39 +1049,25 @@ Here's an example of a project that will fail if the environment is not `node` a ### private -If you set `"private": true` in your package.json, then npm will refuse to -publish it. +If you set `"private": true` in your package.json, then npm will refuse to publish it. This is a way to prevent accidental publication of private repositories. -If you would like to ensure that a given package is only ever published to -a specific registry (for example, an internal registry), then use the -`publishConfig` dictionary described below to override the `registry` -config param at publish-time. +If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the `publishConfig` dictionary described below to override the `registry` config param at publish-time. ### publishConfig -This is a set of config values that will be used at publish-time. It's -especially handy if you want to set the tag, registry or access, so that -you can ensure that a given package is not tagged with "latest", published -to the global public registry or that a scoped module is private by -default. +This is a set of config values that will be used at publish-time. +It's especially handy if you want to set the tag, registry or access, so that you can ensure that a given package is not tagged with "latest", published to the global public registry or that a scoped module is private by default. -See [`config`](/using-npm/config) to see the list of config options that -can be overridden. +See [`config`](/using-npm/config) to see the list of config options that can be overridden. ### workspaces -The optional `workspaces` field is an array of file patterns that describes -locations within the local file system that the install client should look -up to find each [workspace](/using-npm/workspaces) that needs to be -symlinked to the top level `node_modules` folder. +The optional `workspaces` field is an array of file patterns that describes locations within the local file system that the install client should look up to find each [workspace](/using-npm/workspaces) that needs to be symlinked to the top level `node_modules` folder. -It can describe either the direct paths of the folders to be used as -workspaces or it can define globs that will resolve to these same folders. +It can describe either the direct paths of the folders to be used as workspaces or it can define globs that will resolve to these same folders. -In the following example, all folders located inside the folder -`./packages` will be treated as workspaces as long as they have valid -`package.json` files inside them: +In the following example, all folders located inside the folder `./packages` will be treated as workspaces as long as they have valid `package.json` files inside them: ```json { @@ -1222,20 +1086,16 @@ npm will default some values based on package contents. * `"scripts": {"start": "node server.js"}` - If there is a `server.js` file in the root of your package, then npm will - default the `start` command to `node server.js`. + If there is a `server.js` file in the root of your package, then npm will default the `start` command to `node server.js`. * `"scripts":{"install": "node-gyp rebuild"}` - If there is a `binding.gyp` file in the root of your package and you have - not defined an `install` or `preinstall` script, npm will default the - `install` command to compile using node-gyp. + If there is a `binding.gyp` file in the root of your package and you have not defined an `install` or `preinstall` script, npm will default the `install` command to compile using node-gyp. * `"contributors": [...]` - If there is an `AUTHORS` file in the root of your package, npm will treat - each line as a `Name (url)` format, where email and url are - optional. Lines which start with a `#` or are blank, will be ignored. + If there is an `AUTHORS` file in the root of your package, npm will treat each line as a `Name (url)` format, where email and url are optional. + Lines which start with a `#` or are blank, will be ignored. ### SEE ALSO diff --git a/docs/lib/content/configuring-npm/package-lock-json.md b/docs/lib/content/configuring-npm/package-lock-json.md index f3b012175fa0e..579dd49807812 100644 --- a/docs/lib/content/configuring-npm/package-lock-json.md +++ b/docs/lib/content/configuring-npm/package-lock-json.md @@ -6,228 +6,164 @@ description: A manifestation of the manifest ### Description -`package-lock.json` is automatically generated for any operations where npm -modifies either the `node_modules` tree, or `package.json`. It describes the -exact tree that was generated, such that subsequent installs are able to -generate identical trees, regardless of intermediate dependency updates. +`package-lock.json` is automatically generated for any operations where npm modifies either the `node_modules` tree, or `package.json`. +It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates. -This file is intended to be committed into source repositories, and serves -various purposes: +This file is intended to be committed into source repositories, and serves various purposes: -* Describe a single representation of a dependency tree such that - teammates, deployments, and continuous integration are guaranteed to - install exactly the same dependencies. +* Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies. -* Provide a facility for users to "time-travel" to previous states of - `node_modules` without having to commit the directory itself. +* Provide a facility for users to "time-travel" to previous states of `node_modules` without having to commit the directory itself. -* Facilitate greater visibility of tree changes through readable source - control diffs. +* Facilitate greater visibility of tree changes through readable source control diffs. -* Optimize the installation process by allowing npm to skip repeated - metadata resolutions for previously-installed packages. +* Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages. -* As of npm v7, lockfiles include enough information to gain a complete - picture of the package tree, reducing the need to read `package.json` - files, and allowing for significant performance improvements. +* As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read `package.json` files, and allowing for significant performance improvements. When `npm` creates or updates `package-lock.json`, it will infer line endings and indentation from `package.json` so that the formatting of both files matches. ### `package-lock.json` vs `npm-shrinkwrap.json` -Both of these files have the same format, and perform similar functions in -the root of a project. +Both of these files have the same format, and perform similar functions in the root of a project. -The difference is that `package-lock.json` cannot be published, and it will -be ignored if found in any place other than the root project. +The difference is that `package-lock.json` cannot be published, and it will be ignored if found in any place other than the root project. -In contrast, [npm-shrinkwrap.json](/configuring-npm/npm-shrinkwrap-json) allows -publication, and defines the dependency tree from the point encountered. -This is not recommended unless deploying a CLI tool or otherwise using the -publication process for producing production packages. +In contrast, [npm-shrinkwrap.json](/configuring-npm/npm-shrinkwrap-json) allows publication, and defines the dependency tree from the point encountered. +This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages. -If both `package-lock.json` and `npm-shrinkwrap.json` are present in the -root of a project, `npm-shrinkwrap.json` will take precedence and -`package-lock.json` will be ignored. +If both `package-lock.json` and `npm-shrinkwrap.json` are present in the root of a project, `npm-shrinkwrap.json` will take precedence and `package-lock.json` will be ignored. ### Hidden Lockfiles -In order to avoid processing the `node_modules` folder repeatedly, npm as -of v7 uses a "hidden" lockfile present in -`node_modules/.package-lock.json`. This contains information about the -tree, and is used in lieu of reading the entire `node_modules` hierarchy -provided that the following conditions are met: +In order to avoid processing the `node_modules` folder repeatedly, npm as of v7 uses a "hidden" lockfile present in `node_modules/.package-lock.json`. +This contains information about the tree, and is used in lieu of reading the entire `node_modules` hierarchy provided that the following conditions are met: - All package folders it references exist in the `node_modules` hierarchy. -- No package folders exist in the `node_modules` hierarchy that are not - listed in the lockfile. -- The modified time of the file is at least as recent as all of the package - folders it references. - -That is, the hidden lockfile will only be relevant if it was created as -part of the most recent update to the package tree. If another CLI mutates -the tree in any way, this will be detected, and the hidden lockfile will be -ignored. - -Note that it _is_ possible to manually change the _contents_ of a package -in such a way that the modified time of the package folder is unaffected. -For example, if you add a file to `node_modules/foo/lib/bar.js`, then the -modified time on `node_modules/foo` will not reflect this change. If you -are manually editing files in `node_modules`, it is generally best to -delete the file at `node_modules/.package-lock.json`. - -As the hidden lockfile is ignored by older npm versions, it does not -contain the backwards compatibility affordances present in "normal" -lockfiles. That is, it is `lockfileVersion: 3`, rather than -`lockfileVersion: 2`. +- No package folders exist in the `node_modules` hierarchy that are not listed in the lockfile. +- The modified time of the file is at least as recent as all of the package folders it references. + +That is, the hidden lockfile will only be relevant if it was created as part of the most recent update to the package tree. +If another CLI mutates the tree in any way, this will be detected, and the hidden lockfile will be ignored. + +Note that it _is_ possible to manually change the _contents_ of a package in such a way that the modified time of the package folder is unaffected. +For example, if you add a file to `node_modules/foo/lib/bar.js`, then the modified time on `node_modules/foo` will not reflect this change. +If you are manually editing files in `node_modules`, it is generally best to delete the file at `node_modules/.package-lock.json`. + +As the hidden lockfile is ignored by older npm versions, it does not contain the backwards compatibility affordances present in "normal" lockfiles. +That is, it is `lockfileVersion: 3`, rather than `lockfileVersion: 2`. ### Handling Old Lockfiles -When npm detects a lockfile from npm v6 or before during the package -installation process, it is automatically updated to fetch missing -information from either the `node_modules` tree or (in the case of empty -`node_modules` trees or very old lockfile formats) the npm registry. +When npm detects a lockfile from npm v6 or before during the package installation process, it is automatically updated to fetch missing information from either the `node_modules` tree or (in the case of empty `node_modules` trees or very old lockfile formats) the npm registry. ### File Format #### `name` -The name of the package this is a package-lock for. This will match what's -in `package.json`. +The name of the package this is a package-lock for. +This will match what's in `package.json`. #### `version` -The version of the package this is a package-lock for. This will match -what's in `package.json`. +The version of the package this is a package-lock for. +This will match what's in `package.json`. #### `lockfileVersion` -An integer version, starting at `1` with the version number of this -document whose semantics were used when generating this -`package-lock.json`. +An integer version, starting at `1` with the version number of this document whose semantics were used when generating this `package-lock.json`. -Note that the file format changed significantly in npm v7 to track -information that would have otherwise required looking in `node_modules` or -the npm registry. Lockfiles generated by npm v7 will contain -`lockfileVersion: 2`. +Note that the file format changed significantly in npm v7 to track information that would have otherwise required looking in `node_modules` or the npm registry. +Lockfiles generated by npm v7 will contain `lockfileVersion: 2`. -* No version provided: an "ancient" shrinkwrap file from a version of npm - prior to npm v5. +* No version provided: an "ancient" shrinkwrap file from a version of npm prior to npm v5. * `1`: The lockfile version used by npm v5 and v6. -* `2`: The lockfile version used by npm v7 and v8. Backwards compatible to v1 - lockfiles. -* `3`: The lockfile version used by npm v9 and above. Backwards compatible to npm v7. +* `2`: The lockfile version used by npm v7 and v8. Backwards compatible to v1 lockfiles. +* `3`: The lockfile version used by npm v9 and above. + Backwards compatible to npm v7. -npm will always attempt to get whatever data it can out of a lockfile, even -if it is not a version that it was designed to support. +npm will always attempt to get whatever data it can out of a lockfile, even if it is not a version that it was designed to support. #### `packages` -This is an object that maps package locations to an object containing the -information about that package. +This is an object that maps package locations to an object containing the information about that package. -The root project is typically listed with a key of `""`, and all other -packages are listed with their relative paths from the root project folder. +The root project is typically listed with a key of `""`, and all other packages are listed with their relative paths from the root project folder. Package descriptors have the following fields: * version: The version found in `package.json` -* resolved: The place where the package was actually resolved from. In - the case of packages fetched from the registry, this will be a url to a - tarball. In the case of git dependencies, this will be the full git url - with commit sha. In the case of link dependencies, this will be the - location of the link target. `registry.npmjs.org` is a magic value meaning - "the currently configured registry". +* resolved: The place where the package was actually resolved from. + In the case of packages fetched from the registry, this will be a url to a tarball. + In the case of git dependencies, this will be the full git url with commit sha. + In the case of link dependencies, this will be the location of the link target. + `registry.npmjs.org` is a magic value meaning "the currently configured registry". -* 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. +* 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. -* link: A flag to indicate that this is a symbolic link. If this is - present, no other fields are specified, since the link target will also - be included in the lockfile. +* link: A flag to indicate that this is a symbolic link. + If this is present, no other fields are specified, since the link target will also be included in the lockfile. * dev, optional, devOptional: If the package is strictly part of the - `devDependencies` tree, then `dev` will be true. If it is strictly part - of the `optionalDependencies` tree, then `optional` will be set. If it - is both a `dev` dependency _and_ an `optional` dependency of a non-dev - dependency, then `devOptional` will be set. (An `optional` dependency of - a `dev` dependency will have both `dev` and `optional` set.) + `devDependencies` tree, then `dev` will be true. + If it is strictly part of the `optionalDependencies` tree, then `optional` will be set. + If it is both a `dev` dependency _and_ an `optional` dependency of a non-dev dependency, then `devOptional` will be set. + (An `optional` dependency of a `dev` dependency will have both `dev` and `optional` set.) * inBundle: A flag to indicate that the package is a bundled dependency. -* hasInstallScript: A flag to indicate that the package has a `preinstall`, - `install`, or `postinstall` script. +* hasInstallScript: A flag to indicate that the package has a `preinstall`, `install`, or `postinstall` script. -* hasShrinkwrap: A flag to indicate that the package has an - `npm-shrinkwrap.json` file. +* hasShrinkwrap: A flag to indicate that the package has an `npm-shrinkwrap.json` file. -* bin, license, engines, dependencies, optionalDependencies: fields from - `package.json` +* bin, license, engines, dependencies, optionalDependencies: fields from `package.json` #### dependencies Legacy data for supporting versions of npm that use `lockfileVersion: 1`. -This is a mapping of package names to dependency objects. Because the -object structure is strictly hierarchical, symbolic link dependencies are -somewhat challenging to represent in some cases. +This is a mapping of package names to dependency objects. +Because the object structure is strictly hierarchical, symbolic link dependencies are somewhat challenging to represent in some cases. -npm v7 ignores this section entirely if a `packages` section is present, -but does keep it up to date in order to support switching between npm v6 -and npm v7. +npm v7 ignores this section entirely if a `packages` section is present, but does keep it up to date in order to support switching between npm v6 and npm v7. Dependency objects have the following fields: -* version: a specifier that varies depending on the nature of the package, - and is usable in fetching a new copy of it. - - * bundled dependencies: Regardless of source, this is a version number - that is purely for informational purposes. - * registry sources: This is a version number. (eg, `1.2.3`) - * git sources: This is a git specifier with resolved committish. (eg, - `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`) - * http tarball sources: This is the URL of the tarball. (eg, - `https://example.com/example-1.3.0.tgz`) - * local tarball sources: This is the file URL of the tarball. (eg - `file:///opt/storage/example-1.3.0.tgz`) - * local link sources: This is the file URL of the link. (eg - `file:libs/our-module`) - -* 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. - -* 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". - -* bundled: If true, this is the bundled dependency and will be installed - by the parent module. When installing, this module will be extracted - from the parent module during the extract phase, not installed as a - separate dependency. - -* dev: If true then this dependency is either a development dependency ONLY - of the top level module or a transitive dependency of one. This is false - for dependencies that are both a development dependency of the top level - and a transitive dependency of a non-development dependency of the top - level. - -* optional: If true then this dependency is either an optional dependency - ONLY of the top level module or a transitive dependency of one. This is - false for dependencies that are both an optional dependency of the top - level and a transitive dependency of a non-optional dependency of the top - level. - -* requires: This is a mapping of module name to version. This is a list of - everything this module requires, regardless of where it will be - installed. The version should match via normal matching rules a - dependency either in our `dependencies` or in a level higher than us. - -* dependencies: The dependencies of this dependency, exactly as at the top - level. +* version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it. + + * bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes. + * registry sources: This is a version number. + (eg, `1.2.3`) + * git sources: This is a git specifier with resolved committish. + (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`) + * http tarball sources: This is the URL of the tarball. + (eg, `https://example.com/example-1.3.0.tgz`) + * local tarball sources: This is the file URL of the tarball. + (eg `file:///opt/storage/example-1.3.0.tgz`) + * local link sources: This is the file URL of the link. + (eg `file:libs/our-module`) + +* 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. + +* 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". + +* bundled: If true, this is the bundled dependency and will be installed by the parent module. + When installing, this module will be extracted from the parent module during the extract phase, not installed as a separate dependency. + +* dev: If true then this dependency is either a development dependency ONLY of the top level module or a transitive dependency of one. + This is false for dependencies that are both a development dependency of the top level and a transitive dependency of a non-development dependency of the top level. + +* optional: If true then this dependency is either an optional dependency ONLY of the top level module or a transitive dependency of one. + This is false for dependencies that are both an optional dependency of the top level and a transitive dependency of a non-optional dependency of the top level. + +* requires: This is a mapping of module name to version. + This is a list of everything this module requires, regardless of where it will be installed. + The version should match via normal matching rules a dependency either in our `dependencies` or in a level higher than us. + +* dependencies: The dependencies of this dependency, exactly as at the top level. ### See also diff --git a/docs/lib/content/using-npm/config.md b/docs/lib/content/using-npm/config.md index ba0e54d8da9f9..15d53ddf3d7e1 100644 --- a/docs/lib/content/using-npm/config.md +++ b/docs/lib/content/using-npm/config.md @@ -6,35 +6,31 @@ description: More than you probably want to know about npm configuration ### Description -This article details npm configuration in general. To learn about the `config` command, +This article details npm configuration in general. +To learn about the `config` command, see [`npm config`](/commands/npm-config). npm gets its configuration values from the following sources, sorted by priority: #### Command Line Flags -Putting `--foo bar` on the command line sets the `foo` configuration -parameter to `"bar"`. A `--` argument tells the cli parser to stop -reading flags. Using `--flag` without specifying any value will set -the value to `true`. +Putting `--foo bar` on the command line sets the `foo` configuration parameter to `"bar"`. +A `--` argument tells the cli parser to stop reading flags. +Using `--flag` without specifying any value will set the value to `true`. -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. +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. #### Environment Variables -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`](/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. +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`](/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). Notice that you need to use underscores instead of dashes, so `--allow-same-version` @@ -55,8 +51,7 @@ See [npmrc](/configuring-npm/npmrc) for more details. #### Default Configs -Run `npm config ls -l` to see a set of configuration parameters that are -internal to npm, and are defaults if nothing else is specified. +Run `npm config ls -l` to see a set of configuration parameters that are internal to npm, and are defaults if nothing else is specified. ### Shorthands and Other CLI Niceties @@ -64,9 +59,8 @@ The following shorthands are parsed on the command-line: -If the specified configuration param resolves unambiguously to a known -configuration parameter, then it is expanded to that configuration -parameter. For example: +If the specified configuration param resolves unambiguously to a known configuration parameter, then it is expanded to that configuration parameter. +For example: ```bash npm ls --par @@ -74,10 +68,8 @@ npm ls --par npm ls --parseable ``` -If multiple single-character shorthands are strung together, and the -resulting combination is unambiguously not some other configuration -param, then it is expanded to its various component pieces. For -example: +If multiple single-character shorthands are strung together, and the resulting combination is unambiguously not some other configuration param, then it is expanded to its various component pieces. +For example: ```bash npm ls -gpld diff --git a/docs/lib/content/using-npm/dependency-selectors.md b/docs/lib/content/using-npm/dependency-selectors.md index 2ae7efc061086..9a1502e9349da 100644 --- a/docs/lib/content/using-npm/dependency-selectors.md +++ b/docs/lib/content/using-npm/dependency-selectors.md @@ -11,13 +11,15 @@ The [`npm query`](/commands/npm-query) command exposes a new dependency selector - Standardizes the shape of, & querying of, dependency graphs with a robust object model, metadata & selector syntax - Leverages existing, known language syntax & operators from CSS to make disparate package information broadly accessible - Unlocks the ability to answer complex, multi-faceted questions about dependencies, their relationships & associative metadata -- Consolidates redundant logic of similar query commands in `npm` (ex. `npm fund`, `npm ls`, `npm outdated`, `npm audit` ...) +- Consolidates redundant logic of similar query commands in `npm` (ex. +`npm fund`, `npm ls`, `npm outdated`, `npm audit` ...) ### Dependency Selector Syntax #### Overview: -- there is no "type" or "tag" selectors (ex. `div, h1, a`) as a dependency/target is the only type of `Node` that can be queried +- there is no "type" or "tag" selectors (ex. +`div, h1, a`) as a dependency/target is the only type of `Node` that can be queried - the term "dependencies" is in reference to any `Node` found in a `tree` returned by `Arborist` #### Combinators @@ -66,13 +68,17 @@ The [`npm query`](/commands/npm-query) command exposes a new dependency selector ##### `:semver(, [selector], [function])` -The `:semver()` pseudo selector allows comparing fields from each node's `package.json` using [semver](https://github.com/npm/node-semver#readme) methods. It accepts up to 3 parameters, all but the first of which are optional. +The `:semver()` pseudo selector allows comparing fields from each node's `package.json` using [semver](https://github.com/npm/node-semver#readme) methods. +It accepts up to 3 parameters, all but the first of which are optional. - `spec` a semver version or range - `selector` an attribute selector for each node (default `[version]`) - `function` a semver method to apply, one of: `satisfies`, `intersects`, `subset`, `gt`, `gte`, `gtr`, `lt`, `lte`, `ltr`, `eq`, `neq` or the special function `infer` (default `infer`) -When the special `infer` function is used the `spec` and the actual value from the node are compared. If both are versions, according to `semver.valid()`, `eq` is used. If both values are ranges, according to `!semver.valid()`, `intersects` is used. If the values are mixed types `satisfies` is used. +When the special `infer` function is used the `spec` and the actual value from the node are compared. +If both are versions, according to `semver.valid()`, `eq` is used. +If both values are ranges, according to `!semver.valid()`, `intersects` is used. +If the values are mixed types `satisfies` is used. Some examples: @@ -82,7 +88,8 @@ Some examples: ##### `:outdated()` -The `:outdated` pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. The type parameter may be one of the following: +The `:outdated` pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. +The type parameter may be one of the following: - `any` (default) a version exists that is greater than the current one - `in-range` a version exists that is greater than the current one, and satisfies at least one if its parent's dependencies @@ -91,11 +98,14 @@ The `:outdated` pseudo selector retrieves data from the registry and returns inf - `minor` a version exists that is a semver minor greater than the current one - `patch` a version exists that is a semver patch greater than the current one -In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. The following data can be found under the `queryContext` property of each node. +In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. +The following data can be found under the `queryContext` property of each node. - `versions` an array of every available version of the given node -- `outdated.inRange` an array of objects, each with a `from` and `versions`, where `from` is the on-disk location of the node that depends on the current node and `versions` is an array of all available versions that satisfies that dependency. This is only populated if `:outdated(in-range)` is used. -- `outdated.outOfRange` an array of objects, identical in shape to `inRange`, but where the `versions` array is every available version that does not satisfy the dependency. This is only populated if `:outdated(out-of-range)` is used. +- `outdated.inRange` an array of objects, each with a `from` and `versions`, where `from` is the on-disk location of the node that depends on the current node and `versions` is an array of all available versions that satisfies that dependency. +This is only populated if `:outdated(in-range)` is used. +- `outdated.outOfRange` an array of objects, identical in shape to `inRange`, but where the `versions` array is every available version that does not satisfy the dependency. +This is only populated if `:outdated(out-of-range)` is used. Some examples: @@ -104,9 +114,13 @@ Some examples: ##### `:vuln` -The `:vuln` pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. Only dependencies whose current version matches a vulnerability will be returned. For example if you have `semver@7.6.0` in your tree, a vulnerability for `semver` which affects versions `<=6.3.1` will not match. +The `:vuln` pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. +Only dependencies whose current version matches a vulnerability will be returned. +For example if you have `semver@7.6.0` in your tree, a vulnerability for `semver` which affects versions `<=6.3.1` will not match. -You can also filter results by certain attributes in advisories. Currently that includes `severity` and `cwe`. Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified. +You can also filter results by certain attributes in advisories. +Currently that includes `severity` and `cwe`. +Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified. In addition to the filtering performed by the pseudo selector, info about each relevant advisory will be added to the `queryContext` attribute of each node under the `advisories` attribute. @@ -121,7 +135,8 @@ Some examples: The attribute selector evaluates the key/value pairs in `package.json` if they are `String`s. -- `[]` attribute selector (ie. existence of attribute) +- `[]` attribute selector (ie. +existence of attribute) - `[attribute=value]` attribute value is equivalent... - `[attribute~=value]` attribute value contains word... - `[attribute*=value]` attribute value contains string... @@ -131,7 +146,10 @@ The attribute selector evaluates the key/value pairs in `package.json` if they a #### `Array` & `Object` Attribute Selectors -The generic `:attr()` pseudo selector standardizes a pattern which can be used for attribute selection of `Object`s, `Array`s or `Arrays` of `Object`s accessible via `Arborist`'s `Node.package` metadata. This allows for iterative attribute selection beyond top-level `String` evaluation. The last argument passed to `:attr()` must be an `attribute` selector or a nested `:attr()`. See examples below: +The generic `:attr()` pseudo selector standardizes a pattern which can be used for attribute selection of `Object`s, `Array`s or `Arrays` of `Object`s accessible via `Arborist`'s `Node.package` metadata. +This allows for iterative attribute selection beyond top-level `String` evaluation. +The last argument passed to `:attr()` must be an `attribute` selector or a nested `:attr()`. +See examples below: #### `Objects` @@ -151,7 +169,8 @@ Nested objects are expressed as sequential arguments to `:attr()`. #### `Arrays` -`Array`s specifically uses a special/reserved `.` character in place of a typical attribute name. `Arrays` also support exact `value` matching when a `String` is passed to the selector. +`Array`s specifically uses a special/reserved `.` character in place of a typical attribute name. +`Arrays` also support exact `value` matching when a `String` is passed to the selector. ##### Example of an `Array` Attribute Selection: ```css @@ -176,7 +195,11 @@ Nested objects are expressed as sequential arguments to `:attr()`. ### Groups -Dependency groups are defined by the package relationships to their ancestors (ie. the dependency types that are defined in `package.json`). This approach is user-centric as the ecosystem has been taught to think about dependencies in these groups first-and-foremost. Dependencies are allowed to be included in multiple groups (ex. a `prod` dependency may also be a `dev` dependency (in that it's also required by another `dev` dependency) & may also be `bundled` - a selector for that type of dependency would look like: `*.prod.dev.bundled`). +Dependency groups are defined by the package relationships to their ancestors (ie. +the dependency types that are defined in `package.json`). +This approach is user-centric as the ecosystem has been taught to think about dependencies in these groups first-and-foremost. +Dependencies are allowed to be included in multiple groups (ex. +a `prod` dependency may also be a `dev` dependency (in that it's also required by another `dev` dependency) & may also be `bundled` - a selector for that type of dependency would look like: `*.prod.dev.bundled`). - `.prod` - `.dev` @@ -185,7 +208,8 @@ Dependency groups are defined by the package relationships to their ancestors (i - `.bundled` - `.workspace` -Please note that currently `workspace` deps are always `prod` dependencies. Additionally the `.root` dependency is also considered a `prod` dependency. +Please note that currently `workspace` deps are always `prod` dependencies. +Additionally the `.root` dependency is also considered a `prod` dependency. ### Programmatic Usage diff --git a/docs/lib/content/using-npm/developers.md b/docs/lib/content/using-npm/developers.md index b8c0b8d96dca7..0261d137b36b7 100644 --- a/docs/lib/content/using-npm/developers.md +++ b/docs/lib/content/using-npm/developers.md @@ -6,19 +6,16 @@ description: Developer Guide ### Description -So, you've decided to use npm to develop (and maybe publish/deploy) -your project. +So, you've decided to use npm to develop (and maybe publish/deploy) your project. Fantastic! -There are a few things that you need to do above the simple steps -that your users will do to install your program. +There are a few things that you need to do above the simple steps that your users will do to install your program. ### About These Documents -These are man pages. If you install npm, you should be able to -then do `man npm-thing` to get the documentation on a particular -topic, or `npm help thing` to see the same information. +These are man pages. +If you install npm, you should be able to then do `man npm-thing` to get the documentation on a particular topic, or `npm help thing` to see the same information. ### What is a Package @@ -32,10 +29,7 @@ A package is: * f) a `` that has a "latest" tag satisfying (e) * g) a `git` url that, when cloned, results in (a). -Even if you never publish your package, you can still get a lot of -benefits of using npm if you just want to write a node program (a), and -perhaps if you also want to be able to easily install it elsewhere -after packing it up into a tarball (b). +Even if you never publish your package, you can still get a lot of benefits of using npm if you just want to write a node program (a), and perhaps if you also want to be able to easily install it elsewhere after packing it up into a tarball (b). Git urls can be of the form: @@ -46,74 +40,62 @@ git+http://user@hostname/project/blah.git#commit-ish git+https://user@hostname/project/blah.git#commit-ish ``` -The `commit-ish` can be any tag, sha, or branch which can be supplied as -an argument to `git checkout`. The default is whatever the repository uses -as its default branch. +The `commit-ish` can be any tag, sha, or branch which can be supplied as an argument to `git checkout`. +The default is whatever the repository uses as its default branch. ### The package.json File -You need to have a `package.json` file in the root of your project to do -much of anything with npm. That is basically the whole interface. +You need to have a `package.json` file in the root of your project to do much of anything with npm. +That is basically the whole interface. -See [`package.json`](/configuring-npm/package-json) for details about what -goes in that file. At the very least, you need: +See [`package.json`](/configuring-npm/package-json) for details about what goes in that file. +At the very least, you need: -* name: This should be a string that identifies your project. Please do - not use the name to specify that it runs on node, or is in JavaScript. - You can use the "engines" field to explicitly state the versions of node - (or whatever else) that your program requires, and it's pretty well - assumed that it's JavaScript. +* name: This should be a string that identifies your project. + Please do not use the name to specify that it runs on node, or is in JavaScript. + You can use the "engines" field to explicitly state the versions of node (or whatever else) that your program requires, and it's pretty well assumed that it's JavaScript. It does not necessarily need to match your github repository name. - So, `node-foo` and `bar-js` are bad names. `foo` or `bar` are better. + So, `node-foo` and `bar-js` are bad names. + `foo` or `bar` are better. * version: A semver-compatible version. -* engines: Specify the versions of node (or whatever else) that your - program runs on. The node API changes a lot, and there may be bugs or - new functionality that you depend on. Be explicit. +* engines: Specify the versions of node (or whatever else) that your program runs on. + The node API changes a lot, and there may be bugs or new functionality that you depend on. + Be explicit. * author: Take some credit. -* scripts: If you have a special compilation or installation script, then - you should put it in the `scripts` object. You should definitely have at - least a basic smoke-test command as the "scripts.test" field. See - [scripts](/using-npm/scripts). +* scripts: If you have a special compilation or installation script, then you should put it in the `scripts` object. + You should definitely have at least a basic smoke-test command as the "scripts.test" field. + See [scripts](/using-npm/scripts). -* main: If you have a single module that serves as the entry point to your - program (like what the "foo" package gives you at require("foo")), then - you need to specify that in the "main" field. +* main: If you have a single module that serves as the entry point to your program (like what the "foo" package gives you at require("foo")), then you need to specify that in the "main" field. -* directories: This is an object mapping names to folders. The best ones - to include are "lib" and "doc", but if you use "man" to specify a folder - full of man pages, they'll get installed just like these ones. +* directories: This is an object mapping names to folders. + The best ones to include are "lib" and "doc", but if you use "man" to specify a folder full of man pages, they'll get installed just like these ones. -You can use `npm init` in the root of your package in order to get you -started with a pretty basic package.json file. See [`npm -init`](/commands/npm-init) for more info. +You can use `npm init` in the root of your package in order to get you started with a pretty basic package.json file. +See [`npm init`](/commands/npm-init) for more info. ### Keeping files *out* of your Package -Use a `.npmignore` file to keep stuff out of your package. If there's no -`.npmignore` file, but there *is* a `.gitignore` file, then npm will ignore -the stuff matched by the `.gitignore` file. If you *want* to include -something that is excluded by your `.gitignore` file, you can create an -empty `.npmignore` file to override it. Like `git`, `npm` looks for -`.npmignore` and `.gitignore` files in all subdirectories of your package, -not only the root directory. +Use a `.npmignore` file to keep stuff out of your package. +If there's no `.npmignore` file, but there *is* a `.gitignore` file, then npm will ignore the stuff matched by the `.gitignore` file. +If you *want* to include something that is excluded by your `.gitignore` file, you can create an empty `.npmignore` file to override it. +Like `git`, `npm` looks for `.npmignore` and `.gitignore` files in all subdirectories of your package, not only the root directory. -`.npmignore` files follow the [same pattern -rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) -as `.gitignore` files: +`.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) as `.gitignore` files: * Blank lines or lines starting with `#` are ignored. * Standard glob patterns work. * You can end patterns with a forward slash `/` to specify a directory. * You can negate a pattern by starting it with an exclamation point `!`. -By default, some paths and files are ignored, so there's no -need to add them to `.npmignore` explicitly. Some examples are: +By default, some paths and files are ignored, so there's no need to add them to `.npmignore` explicitly. +Some examples are: * `.*.swp` * `._*` @@ -130,39 +112,28 @@ need to add them to `.npmignore` explicitly. Some examples are: * `CVS` * `npm-debug.log` -Additionally, everything in `node_modules` is ignored, except for -bundled dependencies. npm automatically handles this for you, so don't -bother adding `node_modules` to `.npmignore`. +Additionally, everything in `node_modules` is ignored, except for bundled dependencies. +npm automatically handles this for you, so don't bother adding `node_modules` to `.npmignore`. -The following paths and files are never ignored, so adding them to -`.npmignore` is pointless: +The following paths and files are never ignored, so adding them to `.npmignore` is pointless: * `package.json` * `README` (and its variants) * `LICENSE` / `LICENCE` -If, given the structure of your project, you find `.npmignore` to be a -maintenance headache, you might instead try populating the `files` -property of `package.json`, which is an array of file or directory names -that should be included in your package. Sometimes manually picking -which items to allow is easier to manage than building a block list. +If, given the structure of your project, you find `.npmignore` to be a maintenance headache, you might instead try populating the `files` property of `package.json`, which is an array of file or directory names that should be included in your package. +Sometimes manually picking which items to allow is easier to manage than building a block list. -See [`package.json`](/configuring-npm/package-json) for more info on -what can and can't be ignored. +See [`package.json`](/configuring-npm/package-json) for more info on what can and can't be ignored. #### Testing whether your `.npmignore` or `files` config works -If you want to double check that your package will include only the files -you intend it to when published, you can run the `npm pack` command locally -which will generate a tarball in the working directory, the same way it -does for publishing. +If you want to double check that your package will include only the files you intend it to when published, you can run the `npm pack` command locally which will generate a tarball in the working directory, the same way it does for publishing. ### Link Packages -`npm link` is designed to install a development package and see the -changes in real time without having to keep re-installing it. (You do -need to either re-link or `npm rebuild -g` to update compiled packages, -of course.) +`npm link` is designed to install a development package and see the changes in real time without having to keep re-installing it. +(You do need to either re-link or `npm rebuild -g` to update compiled packages, of course.) More info at [`npm link`](/commands/npm-link). @@ -170,9 +141,8 @@ More info at [`npm link`](/commands/npm-link). **This is important.** -If you cannot install it locally, you'll have -problems trying to publish it. Or, worse yet, you'll be able to -publish it, but you'll be publishing a broken or pointless package. +If you cannot install it locally, you'll have problems trying to publish it. +Or, worse yet, you'll be able to publish it, but you'll be publishing a broken or pointless package. So don't do that. In the root of your package, do this: @@ -181,8 +151,8 @@ In the root of your package, do this: npm install . -g ``` -That'll show you that it's working. If you'd rather just create a symlink -package that points to your working directory, then do this: +That'll show you that it's working. +If you'd rather just create a symlink package that points to your working directory, then do this: ```bash npm link @@ -199,12 +169,12 @@ npm install ../my-package to install it locally into the node_modules folder in that other place. -Then go into the node-repl, and try using require("my-thing") to -bring in your module's main module. +Then go into the node-repl, and try using require("my-thing") to bring in your module's main module. ### Create a User Account -Create a user with the adduser command. It works like this: +Create a user with the adduser command. +It works like this: ```bash npm adduser @@ -216,19 +186,17 @@ This is documented better in [npm adduser](/commands/npm-adduser). ### Publish your Package -This part's easy. In the root of your folder, do this: +This part's easy. +In the root of your folder, do this: ```bash npm publish ``` -You can give publish a url to a tarball, or a filename of a tarball, -or a path to a folder. +You can give publish a url to a tarball, or a filename of a tarball, or a path to a folder. -Note that pretty much **everything in that folder will be exposed** -by default. So, if you have secret stuff in there, use a -`.npmignore` file to list out the globs to ignore, or publish -from a fresh checkout. +Note that pretty much **everything in that folder will be exposed** by default. +So, if you have secret stuff in there, use a `.npmignore` file to list out the globs to ignore, or publish from a fresh checkout. ### Brag about it diff --git a/docs/lib/content/using-npm/logging.md b/docs/lib/content/using-npm/logging.md index e55173e1cdafc..ee27ad62c62df 100644 --- a/docs/lib/content/using-npm/logging.md +++ b/docs/lib/content/using-npm/logging.md @@ -12,9 +12,11 @@ The `npm` CLI has various mechanisms for showing different levels of information All logs are written to a debug log, with the path to that file printed if the execution of a command fails. -The default location of the logs directory is a directory named `_logs` inside the npm cache. This can be changed with the `logs-dir` config option. +The default location of the logs directory is a directory named `_logs` inside the npm cache. +This can be changed with the `logs-dir` config option. -For example, if you wanted to write all your logs to the current working directory, you could run: `npm install --logs-dir=.`. This is especially helpful in debugging a specific `npm` issue as you can run +For example, if you wanted to write all your logs to the current working directory, you could run: `npm install --logs-dir=.`. +This is especially helpful in debugging a specific `npm` issue as you can run a command multiple times with different config values and then diff all the log files. Log files will be removed from the `logs-dir` when the number of log files exceeds `logs-max`, with the oldest logs being deleted first. @@ -55,30 +57,31 @@ The log levels listed above have various corresponding aliases, including: #### `foreground-scripts` -The `npm` CLI began hiding the output of lifecycle scripts for `npm install` as of `v7`. Notably, this means you will not see logs/output from packages that may be using "install scripts" to display information back to you or from your own project's scripts defined in `package.json`. If you'd like to change this behavior & log this output you can set `foreground-scripts` to `true`. +The `npm` CLI began hiding the output of lifecycle scripts for `npm install` as of `v7`. +Notably, this means you will not see logs/output from packages that may be using "install scripts" to display information back to you or from your own project's scripts defined in `package.json`. +If you'd like to change this behavior & log this output you can set `foreground-scripts` to `true`. ### Timing Information -The [`--timing` config](/using-npm/config#timing) can be set which does a few -things: +The [`--timing` config](/using-npm/config#timing) can be set which does a few things: 1. Always shows the full path to the debug log regardless of command exit status 1. Write timing information to a process specific timing file in the cache or `logs-dir` 1. Output timing information to the terminal -This file contains a `timers` object where the keys are an identifier for the -portion of the process being timed and the value is the number of milliseconds it took to complete. +This file contains a `timers` object where the keys are an identifier for the portion of the process being timed and the value is the number of milliseconds it took to complete. -Sometimes it is helpful to get timing information without outputting anything to the terminal. For -example, the performance might be affected by writing to the terminal. In this case you can use -`--timing --silent` which will still write the timing file, but not output anything to the terminal -while running. +Sometimes it is helpful to get timing information without outputting anything to the terminal. +For example, the performance might be affected by writing to the terminal. +In this case you can use +`--timing --silent` which will still write the timing file, but not output anything to the terminal while running. ### Registry Response Headers #### `npm-notice` -The `npm` CLI reads from & logs any `npm-notice` headers that are returned from the configured registry. This mechanism can be used by third-party registries to provide useful information when network-dependent requests occur. +The `npm` CLI reads from & logs any `npm-notice` headers that are returned from the configured registry. +This mechanism can be used by third-party registries to provide useful information when network-dependent requests occur. This header is not cached, and will not be logged if the request is served from the cache. @@ -89,7 +92,8 @@ The `npm` CLI makes a best effort to redact the following from terminal output a - Passwords inside basic auth URLs - npm tokens -However, this behavior should not be relied on to keep all possible sensitive information redacted. If you are concerned about secrets in your log file or terminal output, you can use `--loglevel=silent` and `--logs-max=0` to ensure no logs are written to your terminal or filesystem. +However, this behavior should not be relied on to keep all possible sensitive information redacted. +If you are concerned about secrets in your log file or terminal output, you can use `--loglevel=silent` and `--logs-max=0` to ensure no logs are written to your terminal or filesystem. ### See also diff --git a/docs/lib/content/using-npm/orgs.md b/docs/lib/content/using-npm/orgs.md index 0732649f027f8..8faf939d0b5e8 100644 --- a/docs/lib/content/using-npm/orgs.md +++ b/docs/lib/content/using-npm/orgs.md @@ -10,13 +10,17 @@ There are three levels of org users: 1. Super admin, controls billing & adding people to the org. 2. Team admin, manages team membership & package access. -3. Developer, works on packages they are given access to. +3. Developer, works on packages they are given access to. -The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a `developers` team that all users are automatically added to. +The super admin is the only person who can add users to the org because it impacts the monthly bill. +The super admin will use the website to manage membership. +Every org has a `developers` team that all users are automatically added to. -The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals. +The team admin is the person who manages team creation, team membership, and package access for teams. +The team admin grants package access to teams, not individuals. -The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only. +The developer will be able to access packages based on the teams they are on. +Access is either read-write or read-only. There are two main commands: @@ -31,7 +35,8 @@ There are two main commands: npm team ls :developers ``` -* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the `access` command. +* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. +This team automatically gets read-write access to all packages, but you can change that with the `access` command. * Create a new team: diff --git a/docs/lib/content/using-npm/package-spec.md b/docs/lib/content/using-npm/package-spec.md index 1ace780019fb3..71e8cb1706d01 100644 --- a/docs/lib/content/using-npm/package-spec.md +++ b/docs/lib/content/using-npm/package-spec.md @@ -7,12 +7,10 @@ description: Package name specifier ### Description -Commands like `npm install` and the dependency sections in the -`package.json` use a package name specifier. This can be many different -things that all refer to a "package". Examples include a package name, -git url, tarball, or local directory. These will generally be referred -to as `` in the help output for the npm commands that use -this package name specifier. +Commands like `npm install` and the dependency sections in the `package.json` use a package name specifier. +This can be many different things that all refer to a "package". Examples include a package name, +git url, tarball, or local directory. +These will generally be referred to as `` in the help output for the npm commands that use this package name specifier. ### Package name @@ -21,10 +19,8 @@ this package name specifier. * `[<@scope>/]@` * `[<@scope>/]@` -Refers to a package by name, with or without a scope, and optionally -tag, version, or version range. This is typically used in combination -with the [registry](/using-npm/config#registry) config to refer to a -package in a registry. +Refers to a package by name, with or without a scope, and optionally tag, version, or version range. +This is typically used in combination with the [registry](/using-npm/config#registry) config to refer to a package in a registry. Examples: * `npm` @@ -37,15 +33,10 @@ Examples: * `@npm:` -Primarily used by commands like `npm install` and in the dependency -sections in the `package.json`, this refers to a package by an alias. -The `` is the name of the package as it is reified in the -`node_modules` folder, and the `` refers to a package name as -found in the configured registry. +Primarily used by commands like `npm install` and in the dependency sections in the `package.json`, this refers to a package by an alias. +The `` is the name of the package as it is reified in the `node_modules` folder, and the `` refers to a package name as found in the configured registry. -See `Package name` above for more info on referring to a package by -name, and [registry](/using-npm/config#registry) for configuring which -registry is used when referring to a package by name. +See `Package name` above for more info on referring to a package by name, and [registry](/using-npm/config#registry) for configuring which registry is used when referring to a package by name. Examples: * `semver:@npm:@npmcli/semver-with-patch` @@ -56,12 +47,11 @@ Examples: * `` -This refers to a package on the local filesystem. Specifically this is -a folder with a `package.json` file in it. This *should* always be -prefixed with a `/` or `./` (or your OS equivalent) to reduce confusion. -npm currently will parse a string with more than one `/` in it as a -folder, but this is legacy behavior that may be removed in a future -version. +This refers to a package on the local filesystem. +Specifically this is +a folder with a `package.json` file in it. +This *should* always be prefixed with a `/` or `./` (or your OS equivalent) to reduce confusion. +npm currently will parse a string with more than one `/` in it as a folder, but this is legacy behavior that may be removed in a future version. Examples: @@ -78,18 +68,17 @@ Examples: * `./my-package.tgz` * `https://registry.npmjs.org/semver/-/semver-1.0.0.tgz` -Refers to a package in a tarball format, either on the local filesystem -or remotely via url. This is the format that packages exist in when -uploaded to a registry. +Refers to a package in a tarball format, either on the local filesystem or remotely via url. +This is the format that packages exist in when uploaded to a registry. ### git urls * `` * `/` -Refers to a package in a git repo. This can be a full git url, git -shorthand, or a username/package on GitHub. You can specify a -git tag, branch, or other git ref by appending `#ref`. +Refers to a package in a git repo. +This can be a full git url, git shorthand, or a username/package on GitHub. +You can specify a git tag, branch, or other git ref by appending `#ref`. Examples: diff --git a/docs/lib/content/using-npm/registry.md b/docs/lib/content/using-npm/registry.md index d12bd9d23fda7..1dbd41e3090bc 100644 --- a/docs/lib/content/using-npm/registry.md +++ b/docs/lib/content/using-npm/registry.md @@ -6,66 +6,56 @@ description: The JavaScript Package Registry ### Description -To resolve packages by name and version, npm talks to a registry website -that implements the CommonJS Package Registry specification for reading -package info. +To resolve packages by name and version, npm talks to a registry website that implements the CommonJS Package Registry specification for reading package info. npm is configured to use the **npm public registry** at - by default. Use of the npm public registry is -subject to terms of use available at . + by default. +Use of the npm public registry is subject to terms of use available at . -You can configure npm to use any compatible registry you like, and even run -your own registry. Use of someone else's registry may be governed by their -terms of use. +You can configure npm to use any compatible registry you like, and even run your own registry. +Use of someone else's registry may be governed by their terms of use. -npm's package registry implementation supports several -write APIs as well, to allow for publishing packages and managing user -account information. +npm's package registry implementation supports several write APIs as well, to allow for publishing packages and managing user account information. The registry URL used is determined by the scope of the package (see -[`scope`](/using-npm/scope). If no scope is specified, the default registry is -used, which is supplied by the [`registry` config](/using-npm/config#registry) -parameter. See [`npm config`](/commands/npm-config), -[`npmrc`](/configuring-npm/npmrc), and [`config`](/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 +[`scope`](/using-npm/scope). +If no scope is specified, the default registry is used, which is supplied by the [`registry` config](/using-npm/config#registry) +parameter. +See [`npm config`](/commands/npm-config), +[`npmrc`](/configuring-npm/npmrc), and [`config`](/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](/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. +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. ### Does npm send any information about me back to the registry? Yes. -When making requests of the registry npm adds two headers with information -about your environment: +When making requests of the registry npm adds two headers with information about your environment: * `Npm-Scope` – If your project is scoped, this header will contain its - scope. In the future npm hopes to build registry features that use this + scope. +In the future npm hopes to build registry features that use this information to allow you to customize your experience for your organization. * `Npm-In-CI` – Set to "true" if npm believes this install is running in a - continuous integration environment, "false" otherwise. This is detected by + continuous integration environment, "false" otherwise. +This is detected by looking for the following environment variables: `CI`, `TDDIUM`, - `JENKINS_URL`, `bamboo.buildKey`. If you'd like to learn more you may find + `JENKINS_URL`, `bamboo.buildKey`. +If you'd like to learn more you may find the [original PR](https://github.com/npm/npm-registry-client/pull/129) interesting. This is used to gather better metrics on how npm is used by humans, versus build farms. -The npm registry does not try to correlate the information in these headers -with any authenticated accounts that may be used in the same requests. +The npm registry does not try to correlate the information in these headers with any authenticated accounts that may be used in the same requests. ### How can I prevent my package from being published in the official registry? -Set `"private": true` in your `package.json` to prevent it from being -published at all, or +Set `"private": true` in your `package.json` to prevent it from being published at all, or `"publishConfig":{"registry":"http://my-internal-registry.local"}` to force it to be published only to your internal/private registry. diff --git a/docs/lib/content/using-npm/removal.md b/docs/lib/content/using-npm/removal.md index 3b94a7d18f9d7..43be8e95dda26 100644 --- a/docs/lib/content/using-npm/removal.md +++ b/docs/lib/content/using-npm/removal.md @@ -16,20 +16,19 @@ Or, if that fails, please proceed to more severe uninstalling methods. ### More Severe Uninstalling -Usually, the above instructions are sufficient. That will remove -npm, but leave behind anything you've installed. +Usually, the above instructions are sufficient. +That will remove npm, but leave behind anything you've installed. If that doesn't work, or if you require more drastic measures, continue reading. -Note that this is only necessary for globally-installed packages. Local -installs are completely contained within a project's `node_modules` -folder. Delete that folder, and everything is gone unless a package's -install script is particularly ill-behaved. +Note that this is only necessary for globally-installed packages. +Local installs are completely contained within a project's `node_modules` +folder. +Delete that folder, and everything is gone unless a package's install script is particularly ill-behaved. -This assumes that you installed node and npm in the default place. If -you configured node with a different `--prefix`, or installed npm with a -different prefix setting, then adjust the paths accordingly, replacing +This assumes that you installed node and npm in the default place. +If you configured node with a different `--prefix`, or installed npm with a different prefix setting, then adjust the paths accordingly, replacing `/usr/local` with your install prefix. To remove everything npm-related manually: @@ -38,17 +37,15 @@ To remove everything npm-related manually: rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm* ``` -If you installed things *with* npm, then your best bet is to uninstall -them with npm first, and then install them again once you have a -proper install. This can help find any symlinks that are lying -around: +If you installed things *with* npm, then your best bet is to uninstall them with npm first, and then install them again once you have a proper install. +This can help find any symlinks that are lying around: ```bash ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm ``` -Prior to version 0.3, npm used shim files for executables and node -modules. To track those down, you can do the following: +Prior to version 0.3, npm used shim files for executables and node modules. +To track those down, you can do the following: ```bash find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ; diff --git a/docs/lib/content/using-npm/scope.md b/docs/lib/content/using-npm/scope.md index b43fa2e9ff381..3e5ba7d1141d0 100644 --- a/docs/lib/content/using-npm/scope.md +++ b/docs/lib/content/using-npm/scope.md @@ -6,9 +6,12 @@ description: Scoped packages ### Description -All npm packages have a name. Some package names also have a scope. A scope +All npm packages have a name. +Some package names also have a scope. +A scope follows the usual rules for package names (URL-safe characters, no leading dots -or underscores). When used in package names, scopes are preceded by an `@` symbol +or underscores). +When used in package names, scopes are preceded by an `@` symbol and followed by a slash, e.g. ```bash @@ -18,23 +21,18 @@ and followed by a slash, e.g. Scopes are a way of grouping related packages together, and also affect a few things about the way npm treats the package. -Each npm user/organization has their own scope, and only you can add packages -in your scope. This means you don't have to worry about someone taking your -package name ahead of you. Thus it is also a good way to signal official packages -for organizations. +Each npm user/organization has their own scope, and only you can add packages in your scope. +This means you don't have to worry about someone taking your package name ahead of you. +Thus it is also a good way to signal official packages for organizations. -Scoped packages can be published and installed as of `npm@2` and are supported -by the primary npm registry. Unscoped packages can depend on scoped packages and -vice versa. The npm client is backwards-compatible with unscoped registries, -so it can be used to work with scoped and unscoped registries at the same time. +Scoped packages can be published and installed as of `npm@2` and are supported by the primary npm registry. +Unscoped packages can depend on scoped packages and vice versa. +The npm client is backwards-compatible with unscoped registries, so it can be used to work with scoped and unscoped registries at the same time. ### Installing scoped packages -Scoped packages are installed to a sub-folder of the regular installation -folder, e.g. if your other packages are installed in `node_modules/packagename`, -scoped modules will be installed in `node_modules/@myorg/packagename`. The scope -folder (`@myorg`) is simply the name of the scope preceded by an `@` symbol, and can -contain any number of scoped packages. +Scoped packages are installed to a sub-folder of the regular installation folder, e.g. if your other packages are installed in `node_modules/packagename`, scoped modules will be installed in `node_modules/@myorg/packagename`. +The scope folder (`@myorg`) is simply the name of the scope preceded by an `@` symbol, and can contain any number of scoped packages. A scoped package is installed by referencing it by name, preceded by an `@` symbol, in `npm install`: @@ -63,7 +61,8 @@ include the name of the scope when requiring them in your code, e.g. require('@myorg/mypackage') ``` -There is nothing special about the way Node treats scope folders. This +There is nothing special about the way Node treats scope folders. +This simply requires the `mypackage` module in the folder named `@myorg`. ### Publishing scoped packages @@ -87,14 +86,18 @@ Publishing to a scope, you have two options: If publishing a public module to an organization scope, you must first either create an organization with the name of the scope that you'd like to publish to or be added to an existing organization -with the appropriate permissions. For example, if you'd like to +with the appropriate permissions. +For example, if you'd like to publish to `@org`, you would need to create the `org` organization on npmjs.com prior to trying to publish. -Scoped packages are not public by default. You will need to specify -`--access public` with the initial `npm publish` command. This will publish +Scoped packages are not public by default. +You will need to specify +`--access public` with the initial `npm publish` command. +This will publish the package and set access to `public` as if you had run `npm access public` -after publishing. You do not need to do this when publishing new versions of +after publishing. +You do not need to do this when publishing new versions of an existing scoped package. #### Publishing private scoped packages to the npm registry @@ -105,12 +108,14 @@ account. You can then publish the module with `npm publish` or `npm publish --access restricted`, and it will be present in the npm registry, with -restricted access. You can then change the access permissions, if +restricted access. +You can then change the access permissions, if desired, with `npm access` or on the npmjs.com website. ### Associating a scope with a registry -Scopes can be associated with a separate registry. This allows you to +Scopes can be associated with a separate registry. +This allows you to seamlessly use a mix of packages from the primary npm registry and one or more private registries, such as [GitHub Packages](https://github.com/features/packages) or the open source [Verdaccio](https://verdaccio.org) project. @@ -131,7 +136,8 @@ npm config set @myco:registry=http://reg.example.com ``` Once a scope is associated with a registry, any `npm install` for a package -with that scope will request packages from that registry instead. Any +with that scope will request packages from that registry instead. +Any `npm publish` for a package name that contains the scope will be published to that registry instead. diff --git a/docs/lib/content/using-npm/scripts.md b/docs/lib/content/using-npm/scripts.md index 3e71262e1bff5..65bb8d230e540 100644 --- a/docs/lib/content/using-npm/scripts.md +++ b/docs/lib/content/using-npm/scripts.md @@ -6,13 +6,13 @@ description: How npm handles the "scripts" field ### Description -The `"scripts"` property of your `package.json` file supports a number -of built-in scripts and their preset life cycle events as well as -arbitrary scripts. These all can be executed by running -`npm run `. *Pre* and *post* -commands with matching names will be run for those as well (e.g. `premyscript`, -`myscript`, `postmyscript`). Scripts from dependencies can be run with -`npm explore -- npm run `. +The `"scripts"` property of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. +These all can be executed by running `npm run `. +*Pre* and *post* +commands with matching names will be run for those as well (e.g. +`premyscript`, +`myscript`, `postmyscript`). +Scripts from dependencies can be run with `npm explore -- npm run `. ### Pre & Post Scripts @@ -30,19 +30,19 @@ To create "pre" or "post" scripts for any scripts defined in the } ``` -In this example `npm run compress` would execute these scripts as -described. +In this example `npm run compress` would execute these scripts as described. ### Life Cycle Scripts -There are some special life cycle scripts that happen only in certain -situations. These scripts happen in addition to the `pre`, `post`, and +There are some special life cycle scripts that happen only in certain situations. +These scripts happen in addition to the `pre`, `post`, and `` scripts. * `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`, `dependencies` **prepare** (since `npm@4.0.0`) -* Runs BEFORE the package is packed, i.e. during `npm publish` +* Runs BEFORE the package is packed, i.e. +during `npm publish` and `npm pack` * Runs on local `npm install` without any arguments * Runs AFTER `prepublish`, but BEFORE `prepublishOnly` @@ -58,7 +58,8 @@ situations. These scripts happen in addition to the `pre`, `post`, **prepublish** (DEPRECATED) * Does not run during `npm publish`, but does run during `npm ci` - and `npm install`. See below for more info. + and `npm install`. +See below for more info. **prepublishOnly** * Runs BEFORE the package is prepared and packed, ONLY on `npm publish`. @@ -78,19 +79,24 @@ situations. These scripts happen in addition to the `pre`, `post`, **Deprecation Note: prepublish** -Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape). +Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). +It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). +As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. +A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape). See for a much lengthier justification, with further reading, for this change. **Use Cases** -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: +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: * Compiling CoffeeScript source code into JavaScript. * Creating minified versions of JavaScript source code. * Fetching remote resources that your package will use. -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: +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: * You can depend on `coffee-script` as a `devDependency`, and thus your users don't need to have it installed. @@ -101,7 +107,8 @@ The advantage of doing these things at `prepublish` time is that they can be don #### Dependencies -The `dependencies` script is run any time an `npm` command causes changes to the `node_modules` directory. It is run AFTER the changes have been applied and the `package.json` and `package-lock.json` files have been updated. +The `dependencies` script is run any time an `npm` command causes changes to the `node_modules` directory. +It is run AFTER the changes have been applied and the `package.json` and `package-lock.json` files have been updated. ### Life Cycle Operation Order @@ -119,7 +126,7 @@ The `dependencies` script is run any time an `npm` command causes changes to the * `prepare` * `postprepare` - These all run after the actual installation of modules into +These all run after the actual installation of modules into `node_modules`, in order, with no internal actions happening in between #### [`npm diff`](/commands/npm-diff) @@ -138,10 +145,7 @@ These also run when you run `npm install -g ` * `prepare` * `postprepare` -If there is a `binding.gyp` file in the root of your package and you -haven't defined your own `install` or `preinstall` scripts, npm will -default the `install` command to compile using node-gyp via `node-gyp -rebuild` +If there is a `binding.gyp` file in the root of your package and you haven't defined your own `install` or `preinstall` scripts, npm will default the `install` command to compile using node-gyp via `node-gyp rebuild` These are run from the scripts of `` @@ -167,14 +171,13 @@ These are run from the scripts of `` * `postinstall` * `prepare` -`prepare` is only run if the current directory is a symlink (e.g. with -linked packages) +`prepare` is only run if the current directory is a symlink (e.g. +with linked packages) #### [`npm restart`](/commands/npm-restart) If there is a `restart` script defined, these events are run; otherwise, -`stop` and `start` are both run if present, including their `pre` and -`post` iterations) +`stop` and `start` are both run if present, including their `pre` and `post` iterations) * `prerestart` * `restart` @@ -192,9 +195,8 @@ If there is a `restart` script defined, these events are run; otherwise, * `start` * `poststart` -If there is a `server.js` file in the root of your package, then npm -will default the `start` command to `node server.js`. `prestart` and -`poststart` will still run in this case. +If there is a `server.js` file in the root of your package, then npm will default the `start` command to `node server.js`. +`prestart` and `poststart` will still run in this case. #### [`npm stop`](/commands/npm-stop) @@ -216,7 +218,9 @@ will default the `start` command to `node server.js`. `prestart` and #### A Note on a lack of [`npm uninstall`](/commands/npm-uninstall) scripts -While npm v6 had `uninstall` lifecycle scripts, npm v7 does not. Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful. +While npm v6 had `uninstall` lifecycle scripts, npm v7 does not. +Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful. + Reasons for a package removal include: @@ -230,13 +234,15 @@ Due to the lack of necessary context, `uninstall` lifecycle scripts are not impl ### 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. +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 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) @@ -244,20 +250,16 @@ For more details, see: ### User -When npm is run as root, scripts are always run with the effective uid -and gid of the working directory owner. +When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner. ### Environment -Package scripts run in an environment where many pieces of information -are made available regarding the setup of npm and the current state of -the process. +Package scripts run in an environment where many pieces of information are made available regarding the setup of npm and the current state of the process. #### path -If you depend on modules that define executable scripts, like test -suites, then those executables will be added to the `PATH` for -executing the scripts. So, if your package.json has this: +If you depend on modules that define executable scripts, like test suites, then those executables will be added to the `PATH` for executing the scripts. +So, if your package.json has this: ```json { @@ -271,31 +273,23 @@ executing the scripts. So, if your package.json has this: } ``` -then you could run `npm start` to execute the `bar` script, which is -exported into the `node_modules/.bin` directory on `npm install`. +then you could run `npm start` to execute the `bar` script, which is exported into the `node_modules/.bin` directory on `npm install`. #### package.json vars -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. +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. See [`package.json`](/configuring-npm/package-json) for more on package configs. #### current lifecycle event -Lastly, the `npm_lifecycle_event` environment variable is set to -whichever stage of the cycle is being executed. So, you could have a -single script used for different parts of the process which switches -based on what's currently happening. +Lastly, the `npm_lifecycle_event` environment variable is set to whichever stage of the cycle is being executed. +So, you could have a single script used for different parts of the process which switches based on what's currently happening. Objects are flattened following this format, so if you had -`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd -see this in the script: +`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd see this in the script: ```bash process.env.npm_package_scripts_install === "foo.js" @@ -315,12 +309,13 @@ For example, if your package.json contains this: ``` 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 +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. -If you want to run a make command, you can do so. This works just -fine: +If you want to run a make command, you can do so. +This works just fine: ```json { @@ -334,35 +329,43 @@ fine: ### Exiting -Scripts are run by passing the line as a script argument to `/bin/sh` on POSIX systems or `cmd.exe` on Windows. You can control which shell is used by setting the [`script-shell`](/using-npm/config#script-shell) configuration option. +Scripts are run by passing the line as a script argument to `/bin/sh` on POSIX systems or `cmd.exe` on Windows. +You can control which shell is used by setting the [`script-shell`](/using-npm/config#script-shell) configuration option. -If the script exits with a code other than 0, then this will abort the -process. +If the script exits with a code other than 0, then this will abort the process. Note that these script files don't have to be Node.js or even -JavaScript programs. They just have to be some kind of executable -file. +JavaScript programs. +They just have to be some kind of executable file. ### Best Practices * Don't exit with a non-zero error code unless you *really* mean it. If the failure is minor or only will prevent some optional features, then it's better to just print a warning and exit successfully. -* Try not to use scripts to do what npm can do for you. Read through +* Try not to use scripts to do what npm can do for you. +Read through [`package.json`](/configuring-npm/package-json) to see all the things that you can specify and enable - by simply describing your package appropriately. In general, this + by simply describing your package appropriately. +In general, this will lead to a more robust and consistent state. -* Inspect the env to determine where to put things. For instance, if +* 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 + 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` +* 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. ### See Also diff --git a/docs/lib/content/using-npm/workspaces.md b/docs/lib/content/using-npm/workspaces.md index 34819b801e5fb..86dac0b94bb83 100644 --- a/docs/lib/content/using-npm/workspaces.md +++ b/docs/lib/content/using-npm/workspaces.md @@ -6,19 +6,12 @@ description: Working with workspaces ### Description -**Workspaces** is a generic term that refers to the set of features in the -npm cli that provides support for managing multiple packages from your local -file system from within a singular top-level, root package. - -This set of features makes up for a much more streamlined workflow handling -linked packages from the local file system. It automates the linking process -as part of `npm install` and removes the need to manually use `npm link` in -order to add references to packages that should be symlinked into the current -`node_modules` folder. - -We also refer to these packages being auto-symlinked during `npm install` as a -single **workspace**, meaning it's a nested package within the current local -file system that is explicitly defined in the [`package.json`](/configuring-npm/package-json#workspaces) +**Workspaces** is a generic term that refers to the set of features in the npm cli that provides support for managing multiple packages from your local file system from within a singular top-level, root package. + +This set of features makes up for a much more streamlined workflow handling linked packages from the local file system. +It automates the linking process as part of `npm install` and removes the need to manually use `npm link` in order to add references to packages that should be symlinked into the current `node_modules` folder. + +We also refer to these packages being auto-symlinked during `npm install` as a single **workspace**, meaning it's a nested package within the current local file system that is explicitly defined in the [`package.json`](/configuring-npm/package-json#workspaces) `workspaces` configuration. ### Defining workspaces @@ -35,9 +28,7 @@ Workspaces are usually defined via the `workspaces` property of the } ``` -Given the above `package.json` example living at a current working -directory `.` that contains a folder named `packages/a` that itself contains -a `package.json` inside it, defining a Node.js package, e.g: +Given the above `package.json` example living at a current working directory `.` that contains a folder named `packages/a` that itself contains a `package.json` inside it, defining a Node.js package, e.g: ``` . @@ -47,12 +38,9 @@ a `package.json` inside it, defining a Node.js package, e.g: | `-- package.json ``` -The expected result once running `npm install` in this current working -directory `.` is that the folder `packages/a` will get symlinked to the -`node_modules` folder of the current working dir. +The expected result once running `npm install` in this current working directory `.` is that the folder `packages/a` will get symlinked to the `node_modules` folder of the current working dir. -Below is a post `npm install` example, given that same previous example -structure of files and folders: +Below is a post `npm install` example, given that same previous example structure of files and folders: ``` . @@ -68,8 +56,8 @@ structure of files and folders: ### Getting started with workspaces You may automate the required steps to define a new workspace using -[npm init](/commands/npm-init). For example in a project that already has a -`package.json` defined you can run: +[npm init](/commands/npm-init). +For example in a project that already has a `package.json` defined you can run: ``` npm init -w ./packages/a @@ -81,8 +69,7 @@ file (if needed) while also making sure to properly configure the ### Adding dependencies to a workspace -It's possible to directly add/remove/update dependencies of your workspaces -using the [`workspace` config](/using-npm/config#workspace). +It's possible to directly add/remove/update dependencies of your workspaces using the [`workspace` config](/using-npm/config#workspace). For example, assuming the following structure: @@ -96,23 +83,18 @@ For example, assuming the following structure: `-- package.json ``` -If you want to add a dependency named `abbrev` from the registry as a -dependency of your workspace **a**, you may use the workspace config to tell -the npm installer that package should be added as a dependency of the provided -workspace: +If you want to add a dependency named `abbrev` from the registry as a dependency of your workspace **a**, you may use the workspace config to tell the npm installer that package should be added as a dependency of the provided workspace: ``` npm install abbrev -w a ``` -Note: other installing commands such as `uninstall`, `ci`, etc will also -respect the provided `workspace` configuration. +Note: other installing commands such as `uninstall`, `ci`, etc will also respect the provided `workspace` configuration. ### Using workspaces -Given the [specifics of how Node.js handles module resolution](https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together) it's possible to consume any defined workspace -by its declared `package.json` `name`. Continuing from the example defined -above, let's also create a Node.js script that will require the workspace `a` +Given the [specifics of how Node.js handles module resolution](https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together) it's possible to consume any defined workspace by its declared `package.json` `name`. +Continuing from the example defined above, let's also create a Node.js script that will require the workspace `a` example module, e.g: ``` @@ -130,18 +112,16 @@ When running it with: This demonstrates how the nature of `node_modules` resolution allows for **workspaces** to enable a portable workflow for requiring each **workspace** -in such a way that is also easy to [publish](/commands/npm-publish) these -nested workspaces to be consumed elsewhere. +in such a way that is also easy to [publish](/commands/npm-publish) these nested workspaces to be consumed elsewhere. ### Running commands in the context of workspaces -You can use the `workspace` configuration option to run commands in the context -of a configured workspace. +You can use the `workspace` configuration option to run commands in the context of a configured workspace. Additionally, if your current directory is in a workspace, the `workspace` configuration is implicitly set, and `prefix` is set to the root workspace. -Following is a quick example on how to use the `npm run` command in the context -of nested workspaces. For a project containing multiple workspaces, e.g: +Following is a quick example on how to use the `npm run` command in the context of nested workspaces. +For a project containing multiple workspaces, e.g: ``` . @@ -153,8 +133,8 @@ of nested workspaces. For a project containing multiple workspaces, e.g: `-- package.json ``` -By running a command using the `workspace` option, it's possible to run the -given command in the context of that specific workspace. e.g: +By running a command using the `workspace` option, it's possible to run the given command in the context of that specific workspace. +e.g: ``` npm run test --workspace=a @@ -169,8 +149,7 @@ cd packages/a && npm run test Either will run the `test` script defined within the `./packages/a/package.json` file. -Please note that you can also specify this argument multiple times in the -command-line in order to target multiple workspaces, e.g: +Please note that you can also specify this argument multiple times in the command-line in order to target multiple workspaces, e.g: ``` npm run test --workspace=a --workspace=b @@ -181,9 +160,9 @@ Or run the command for each workspace within the 'packages' folder: npm run test --workspace=packages ``` -It's also possible to use the `workspaces` (plural) configuration option to -enable the same behavior but running that command in the context of **all** -configured workspaces. e.g: +It's also possible to use the `workspaces` (plural) configuration option to enable the same behavior but running that command in the context of **all** +configured workspaces. +e.g: ``` npm run test --workspaces