\n\nNote: If you introduce a change that breaks a package dependency, we strongly recommend incrementing the version major number; see below for details.\n\n
\n\n## Incrementing semantic versions in published packages\n\nTo help developers who rely on your code, we recommend starting your package version at `1.0.0` and incrementing as follows:\n\n| Code status | Stage | Rule | Example version |\n|-------------|-------|------|----------------|\n| First release | New product | Start with 1.0.0 | 1.0.0 |\n| Backward compatible bug fixes | Patch release | Increment the third digit | 1.0.1 |\n| Backward compatible new features | Minor release | Increment the middle digit and reset last digit to zero | 1.1.0 |\n| Changes that break backward compatibility | Major release | Increment the first digit and reset middle and last digits to zero | 2.0.0 |\n\n## Using semantic versioning to specify update types your package can accept\n\nYou can specify which update types your package can accept from dependencies in your package's `package.json` file.\n\nFor example, to specify acceptable version ranges up to 1.0.4, use the following syntax:\n\n* Patch releases: `1.0` or `1.0.x` or `~1.0.4`\n* Minor releases: `1` or `1.x` or `^1.0.4`\n* Major releases: `*` or `x`\n\nFor more information on semantic versioning syntax, see the [npm semver calculator][semver-calc].\n\n### Example\n\n```json\n\n\"dependencies\": {\n \"my_dep\": \"^1.0.0\",\n \"another_dep\": \"~2.2.0\"\n},\n```\n\n## Resources\n\n\n\n\n[semver-calc]: https://semver.npmjs.com/\n[pkg-json]: creating-a-package-json-file\n[semver-org]: http://semver.org/\n[semver-video]: https://www.youtube.com/embed/kK4Meix58R4\n"},{"id":"37558650-3014-5356-a5e5-fd38dac4e8a6","frontmatter":{"title":"Adding dist-tags to packages"},"rawBody":"---\ntitle: Adding dist-tags to packages\nredirect_from:\n - /getting-started/using-tags/\n---\n\nDistribution tags (dist-tags) are human-readable labels that you can use to organize and label different versions of packages you publish. dist-tags supplement [semantic versioning][semver]. In addition to being more human-readable than semantic version numbering, tags allow publishers to distribute their packages more effectively.\n\nFor more information, see the [`dist-tag` CLI documentation][dist-tag].\n\n\n\n**Note:** Since dist-tags share a namespace with semantic versions, avoid dist-tags that conflict with existing version numbers. We recommend avoiding dist-tags that start with a number or the letter \"v\".\n\n\n\n## Publishing a package with a dist-tag\n\nBy default, running `npm publish` will tag your package with the `latest` dist-tag. To use another dist-tag, use the `--tag` flag when publishing.\n\n1. On the command line, navigate to the root directory of your package.\n\n ```\n cd /path/to/package\n ```\n\n2. Run the following command, replacing `` with the tag you want to use:\n\n ```\n npm publish --tag \n ```\n\n### Example\n\nTo publish a package with the \"beta\" dist-tag, on the command line, run the following command in the root directory of your package:\n\n```\nnpm publish --tag beta\n```\n\n## Adding a dist-tag to a specific version of your package\n\n1. On the command line, navigate to the root directory of your package.\n\n ```\n cd /path/to/package\n ```\n\n2. Run the following command, replacing `` with the name of your package, `` with your package version number, and `` with the distribution tag:\n\n ```\n npm dist-tag add @ []\n ```\n\n### Example\n\nTo add the \"stable\" tag to the 1.4.0 version of the \"example-package\" package, you would run the following command:\n\n```\nnpm dist-tag add example-package@1.4.0 stable\n```\n\n\n[semver]: about-semantic-versioning\n[dist-tag]: /cli/dist-tag\n"},{"id":"233012ba-94cb-56c7-bd1e-2fe6e89c78a1","frontmatter":{"title":"Creating a package.json file"},"rawBody":"---\ntitle: Creating a package.json file\nredirect_from:\n - /about-package-json-and-package-lock-json-files\n - /getting-started/using-a-package.json\n---\n\nYou can add a `package.json` file to your package to make it easy for others to manage and install. Packages published to the registry must contain a `package.json` file.\n\nA `package.json` file:\n\n* lists the packages your project depends on\n* specifies versions of a package that your project\ncan use using [semantic versioning rules][semver]\n* makes your build reproducible, and therefore easier\nto share with other developers\n\n\n\n**Note:** To make your package easier to find on the npm website, we recommend including a custom `description` in your `package.json` file.\n\n\n\n## `package.json` fields\n\n### Required `name` and `version` fields\n\nA `package.json` file must contain `\"name\"` and `\"version\"` fields.\n\nThe `\"name\"` field contains your package's name, and must be lowercase and one word, and may contain hyphens and underscores.\n\nThe `\"version\"` field must be in the form `x.x.x` and follow the [semantic versioning guidelines][semver].\n\n### Author field\n\nIf you want to include package author information in `\"author\"` field, use the following format (email and website are both optional):\n\n```\nYour Name (http://example.com)\n```\n\n### Example\n\n```\n{\n \"name\": \"my-awesome-package\",\n \"version\": \"1.0.0\"\n}\n```\n\n## Creating a new `package.json` file\n\nYou can create a `package.json` file by running a CLI questionnaire or creating a default `package.json` file.\n\n### Running a CLI questionnaire\n\nTo create a `package.json` file with values that you supply, use the `npm init` command.\n\n1. On the command line, navigate to the root directory of your package.\n\n ```\n cd /path/to/package\n ```\n\n2. Run the following command:\n\n ```\n npm init\n ```\n\n3. Answer the questions in the command line questionnaire.\n\n#### Customizing the `package.json` questionnaire\n\nIf you expect to create many `package.json` files, you can customize the questions asked and fields created during the `init` process so all the `package.json` files contain a standard set of information.\n\n\n1. In your home directory, create a file called `.npm-init.js`.\n\n2. To add custom questions, using a text editor, add questions with the `prompt` function:\n\n ```\n module.exports = prompt(\"what's your favorite flavor of ice cream, buddy?\", \"I LIKE THEM ALL\");\n ```\n\n3. To add custom fields, using a text editor, add desired fields to the `.npm-init.js` file:\n\n ```\n module.exports = {\n customField: 'Example custom field',\n otherCustomField: 'This example field is really cool'\n }\n ```\n\nTo learn more about creating advanced `npm init` customizations, see the [init-package-json][init-pkg-json] GitHub repository.\n\n### Creating a default `package.json` file\n\nTo create a default `package.json` using information extracted from the current directory, use the `npm init` command with the `--yes`\nor `-y` flag. For a list of default values, see \"[Default values extracted from the current directory](#default-values-extracted-from-the-current-directory)\".\n\n1. On the command line, navigate to the root directory of your package.\n\n ```\n cd /path/to/package\n ```\n\n2. Run the following command:\n\n ```\n npm init --yes\n ```\n\n#### Example\n\n```\n> npm init --yes\nWrote to /home/monatheoctocat/my_package/package.json:\n\n{\n \"name\": \"my_package\",\n \"description\": \"\",\n \"version\": \"1.0.0\",\n \"scripts\": {\n \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\"\n },\n \"repository\": {\n \"type\": \"git\",\n \"url\": \"https://github.com/monatheoctocat/my_package.git\"\n },\n \"keywords\": [],\n \"author\": \"\",\n \"license\": \"ISC\",\n \"bugs\": {\n \"url\": \"https://github.com/monatheoctocat/my_package/issues\"\n },\n \"homepage\": \"https://github.com/monatheoctocat/my_package\"\n}\n```\n\n#### Default values extracted from the current directory\n\n - `name`: the current directory name\n - `version`: always `1.0.0`\n - `description`: info from the README, or an empty string `\"\"`\n - `scripts`: by default creates an empty `test` script\n - `keywords`: empty\n - `author`: empty\n - `license`: [`ISC`][isc-license]\n - `bugs`: information from the current directory, if present\n - `homepage`: information from the current directory, if present\n\n### Setting config options for the init command\n\nYou can set default config options for the init command. For example, to set the default author email, author name, and license, on the command line, run the following commands:\n\n```\n> npm set init-author-email \"example-user@example.com\"\n> npm set init-author-name \"example_user\"\n> npm set init-license \"MIT\"\n```\n\n[semver]: about-semantic-versioning\n[init-pkg-json]: https://github.com/npm/init-package-json\n[isc-license]: https://opensource.org/licenses/ISC\n"},{"id":"d99e4216-f95b-5f5c-ad70-73e79e1e12ac","frontmatter":{"title":"Creating and publishing private packages"},"rawBody":"---\ntitle: Creating and publishing private packages\nredirect_from:\n - /private-modules/intro\n---\nimport shared from '../../../src/shared.js'\n\nTo share your code with a limited set of users or teams, you can publish private user-scoped or organization-scoped packages to the npm registry.\n\nFor more information on scopes and private packages, see \"[About scopes][scopes]\" and \"[About private packages][private-pkgs]\".\n\n\n\n**Note:** Before you can publish private user-scoped npm packages, you must sign up for a paid npm user account.\n\nAdditionally, to publish private organization-scoped packages, you must create an npm user account, then \ncreate a paid npm organization.\n\n\n\n## Creating a private package\n\n1. If you are using npmrc to [manage accounts on multiple registries][reg-config], on the command line, switch to the appropriate profile:\n\n ```\n npmrc \n ```\n\n2. On the command line, create a directory for your package:\n\n ```\n mkdir my-test-package\n ```\n\n3. Navigate to the root directory of your package:\n\n ```\n cd my-test-package\n ```\n\n4. If you are using git to manage your package code, in the package root directory, run the following commands, replacing `git-remote-url` with the git remote URL for your package:\n\n ```\n git init\n git remote add origin git://git-remote-url\n ```\n\n5. In the package root directory, run the `npm init` command and pass the scope to the `scope` flag:\n\n * For an organization-scoped package, replace `my-org` with the name of your organization:\n ```\n npm init --scope=@my-org\n ```\n\n * For a user-scoped package, replace `my-username` with your username:\n ```\n npm init --scope=@my-username\n ```\n\n6. Respond to the prompts to generate a `package.json` file. For help naming your package, see \"[Package name guidelines][pkg-name]\".\n\n7. Create a [README file][readme-file] that explains what your package code is and how to use it.\n\n8. In your preferred text editor, write the code for your package.\n\n## Reviewing package contents for sensitive or unnecessary information\n\nPublishing sensitive information to the registry can harm your users, compromise your development infrastructure, be expensive to fix, and put you at risk of legal action. **We strongly recommend removing sensitive information, such as private keys, passwords, [personally identifiable information][pii] (PII), and credit card data before publishing your package to the registry.** Even if your package is private, sensitive information can be exposed if the package is made public or downloaded to a computer that can be accessed by more users than intended.\n\nFor less sensitive information, such as testing data, use a `.npmignore` or `.gitignore` file to prevent publishing to the registry. For more information, see [this article][developers].\n\n## Testing your package\n\nTo reduce the chances of publishing bugs, we recommend testing your package before publishing it to the npm registry. To test your package, run `npm install` with the full path to your package directory:\n\n```\nnpm install my-package\n```\n\n## Publishing private packages\n\nBy default, scoped packages are published with private visibility.\n\n1. On the command line, navigate to the root directory of your package.\n\n ```\n cd /path/to/package\n ```\n\n2. To publish your private package to the npm registry, run:\n\n ```\n npm publish\n ```\n\n3. To see your private package page, visit https://npmjs.com/package/*package-name*, replacing *package-name* with the name of your package. Private packages will say `private` below the package name on the npm website.\n\n <>{shared['organization-package-private'].image}\n\nFor more information on the `publish` command, see the [CLI documentation][cli-publish].\n\n[scopes]: about-scopes\n[private-pkgs]: about-private-packages\n[user-signup]: https://www.npmjs.com/signup\n[create-org]: https://www.npmjs.com/signup?next=/org/create\n[pkg-name]: package-name-guidelines\n[readme-file]: about-package-readme-files\n[developers]: /misc/developers#keeping-files-out-of-your-package\n[cli-publish]: /cli/publish\n[reg-config]: configuring-your-registry-settings-as-an-npm-enterprise-user#using-npmrc-to-manage-multiple-profiles-for-different-registries\n"},{"id":"f60de04f-5cf2-5aa6-88f3-99d8c030e19e","frontmatter":{"title":"Creating and publishing scoped public packages"},"rawBody":"---\ntitle: Creating and publishing scoped public packages\n---\nimport shared from '../../../src/shared.js'\n\nTo share your code publicly in a user or organization namespace, you can publish public user-scoped or organization-scoped packages to the npm registry.\n\nFor more information on scopes, see \"[About scopes][scopes]\".\n\n\n\n**Note:** Before you can publish user-scoped npm packages, you must sign up for an npm user account.\n\nAdditionally, to publish organization-scoped packages, you must create an npm user account, then create an npm organization.\n\n\n\n## Creating a scoped public package\n\n1. If you are using npmrc to [manage accounts on multiple registries][reg-config], on the command line, switch to the appropriate profile:\n\n ```\n npmrc \n ```\n\n2. On the command line, create a directory for your package:\n\n ```\n mkdir my-test-package\n ```\n\n3. Navigate to the root directory of your package:\n\n ```\n cd my-test-package\n ```\n\n4. If you are using git to manage your package code, in the package root directory, run the following commands, replacing `git-remote-url` with the git remote URL for your package:\n\n ```\n git init\n git remote add origin git://git-remote-url\n ```\n\n5. In the package root directory, run the `npm init` command and pass the scope to the `scope` flag:\n\n * For an organization-scoped package, replace `my-org` with the name of your organization:\n ```\n npm init --scope=@my-org\n ```\n\n * For a user-scoped package, replace `my-username` with your username:\n ```\n npm init --scope=@my-username\n ```\n\n6. Respond to the prompts to generate a `package.json` file. For help naming your package, see \"[Package name guidelines][pkg-name]\".\n7. Create a [README file][readme-file] that explains what your package code is and how to use it.\n8. In your preferred text editor, write the code for your package.\n\n## Reviewing package contents for sensitive or unnecessary information\n\nPublishing sensitive information to the registry can harm your users, compromise your development infrastructure, be expensive to fix, and put you at risk of legal action. **We strongly recommend removing sensitive information, such as private keys, passwords, [personally identifiable information][pii] (PII), and credit card data before publishing your package to the registry.**\n\nFor less sensitive information, such as testing data, use a `.npmignore` or `.gitignore` file to prevent publishing to the registry. For more information, see [this article][developers].\n\n## Testing your package\n\nTo reduce the chances of publishing bugs, we recommend testing your package before publishing it to the npm registry. To test your package, run `npm install` with the full path to your package directory:\n\n```\nnpm install my-package\n```\n\n## Publishing scoped public packages\n\nBy default, scoped packages are published with private visibility. To publish a scoped package with public visibility, use `npm publish --access public`.\n\n1. On the command line, navigate to the root directory of your package.\n\n ```\n cd /path/to/package\n ```\n\n2. To publish your scoped public package to the npm registry, run:\n\n ```\n npm publish --access public\n ```\n\n3. To see your public package page, visit https://npmjs.com/package/\\*package-name\\*, replacing \\*package-name\\* with the name of your package. Public packages will say `public` below the package name on the npm website.\n\n <>{shared['organization-package-public'].image}\n\nFor more information on the `publish` command, see the [CLI documentation][cli-publish].\n\n\n[scopes]: about-scopes\n[user-signup]: https://www.npmjs.com/signup\n[create-org]: https://www.npmjs.com/signup?next=/org/create\n[reg-config]: configuring-your-registry-settings-as-an-npm-enterprise-user\n[pkg-name]: package-name-guidelines\n[readme-file]: about-package-readme-files\n[developers]: /misc/developers#keeping-files-out-of-your-package\n[cli-publish]: /cli/publish\n[pii]: https://en.wikipedia.org/wiki/Personally_identifiable_information\n"},{"id":"eabc01d0-cc01-5360-a41a-b7c5b9b5da7b","frontmatter":{"title":"Creating and publishing unscoped public packages"},"rawBody":"---\ntitle: Creating and publishing unscoped public packages\n---\n\nAs an npm user, you can create unscoped packages to use in your own projects and publish them to the npm public registry for others to use in theirs. Unscoped packages are always public and are referred to by the package name only:\n\n```\npackage-name\n```\n\nFor more information on package scope, access, and visibility, see \"[Package scope, access level, and visibility][pkg-viz]\".\n\n\n\n**Note:** Before you can publish public unscoped npm packages, you must sign up for an npm user account.\n\n\n\n## Creating an unscoped public package\n\n1. On the command line, create a directory for your package:\n\n ```\n mkdir my-test-package\n ```\n\n2. Navigate to the root directory of your package:\n\n ```\n cd my-test-package\n ```\n\n3. If you are using git to manage your package code, in the package root directory, run the following commands, replacing `git-remote-url` with the git remote URL for your package:\n\n ```\n git init\n git remote add origin git://git-remote-url\n ```\n\n4. In the package root directory, run the `npm init` command.\n5. Respond to the prompts to generate a `package.json` file. For help naming your package, see \"[Package name guidelines][pkg-name]\".\n6. Create a [README file][readme-file] that explains what your package code is and how to use it.\n7. In your preferred text editor, write the code for your package.\n\n## Reviewing package contents for sensitive or unnecessary information\n\nPublishing sensitive information to the registry can harm your users, compromise your development infrastructure, be expensive to fix, and put you at risk of legal action. **We strongly recommend removing sensitive information, such as private keys, passwords, [personally identifiable information][pii] (PII), and credit card data before publishing your package to the registry.**\n\nFor less sensitive information, such as testing data, use a `.npmignore` or `.gitignore` file to prevent publishing to the registry. For more information, see [this article][developers].\n\n## Testing your package\n\nTo reduce the chances of publishing bugs, we recommend testing your package before publishing it to the npm registry. To test your package, run `npm install` with the full path to your package directory:\n\n```\nnpm install my-package\n```\n\n## Publishing unscoped public packages\n\n1. On the command line, navigate to the root directory of your package.\n\n ```\n cd /path/to/package\n ```\n\n2. To publish your public package to the npm registry, run:\n\n ```\n npm publish\n ```\n\n3. To see your public package page, visit https://npmjs.com/package/*package-name*, replacing *package-name* with the name of your package. Public packages will say `public` below the package name on the npm website.\n\nFor more information on the `publish` command, see the [CLI documentation][cli-publish].\n\n\n[pkg-viz]: package-scope-access-level-and-visibility\n[user-signup]: https://www.npmjs.com/signup\n[create-org]: https://www.npmjs.com/signup?next=/org/create\n[pkg-name]: package-name-guidelines\n[readme-file]: about-package-readme-files\n[developers]: /misc/developers#keeping-files-out-of-your-package\n[cli-publish]: /cli/publish\n[pii]: https://en.wikipedia.org/wiki/Personally_identifiable_information\n"},{"id":"fdcd1921-0305-52ea-8756-68aee89ea71e","frontmatter":{"title":"Creating Node.js modules"},"rawBody":"---\ntitle: Creating Node.js modules\nredirect_from:\n - /getting-started/creating-node-modules\n---\n\nNode.js modules are a type of [package][about-pkgs] that can be published to npm.\n\n## Overview\n\n1. [Create a `package.json` file](#create-a-package-json-file)\n2. [Create the file that will be loaded when your module is required by another application](#create-the-file-that-will-be-loaded-when-your-module-is-required-by-another-application)\n3. [Test your module](#test-your-module)\n\n## Create a `package.json` file\n\n1. To create a `package.json` file, on the command line, in the root directory of your Node.js module, run `npm init`:\n - For [scoped modules][scoped-pkg], run `npm init --scope=@scope-name`\n - For [unscoped modules][unscoped-pkg], run `npm init`\n2. Provide responses for the required fields (`name` and `version`), as well as the `main` field:\n - `name`: The name of your module.\n - `version`: The initial module version. We recommend following [semantic versioning guidelines][semver] and starting with `1.0.0`.\n\nFor more information on `package.json` files, see \"[Creating a package.json file][creating-pkg-json]\".\n\n## Create the file that will be loaded when your module is required by another application\n\n\nIn the file, add a function as a property of the `exports` object. This will make the function available to other code:\n\n```\nexports.printMsg = function() {\n console.log(\"This is a message from the demo package\");\n}\n```\n\n## Test your module\n\n1. Publish your package to npm:\n\n - For [private packages][priv-pkg-pub] and [unscoped packages][unscoped-pkg-pub], use `npm publish`.\n - For [scoped public packages][scoped-pkg-pub], use `npm publish --access public`\n\n2. On the command line, create a new test directory outside of your project directory.\n\n ```\n mkdir test-directory\n ```\n\n3. Switch to the new directory:\n\n ```\n cd /path/to/test-directory\n ```\n\n4. In the test directory, install your module:\n\n ```\n npm install \n ```\n\n5. In the test directory, create a `test.js` file which requires your module and calls your module as a method.\n\n6. On the command line, run `node test.js`. The message sent to the console.log should appear.\n\n## Resources\n\n\n\n\n[about-pkgs]: about-packages-and-modules\n[scoped-pkg]: about-scopes\n[unscoped-pkg]: creating-and-publishing-unscoped-public-packages\n[semver]: about-semantic-versioning\n[creating-pkg-json]: creating-a-package-json-file\n[priv-pkg-pub]: creating-and-publishing-private-packages#publishing-private-packages\n[unscoped-pkg-pub]: creating-and-publishing-unscoped-public-packages#publishing-unscoped-public-packages\n[scoped-pkg-pub]: creating-and-publishing-scoped-public-packages#publishing-scoped-public-packages\n"},{"id":"80254e39-35b3-5d35-857a-d58e7e7b37b7","frontmatter":{"title":"Contributing packages to the registry"},"rawBody":"---\ntitle: Contributing packages to the registry\nredirect_from: [ /getting-started/publishing-npm-packages ]\n---\n\n\n\n"},{"id":"7649271c-dacc-5c62-9a3d-a0b654eae11a","frontmatter":{"title":"Package name guidelines"},"rawBody":"---\ntitle: Package name guidelines\n---\n\nWhen choosing a name for your package, choose a name that\n\n- is unique\n- is descriptive\n- meets [npm policy guidelines][policies]. For example, do not give your package an offensive name, and do not use someone else's trademarked name or violate the [npm trademark policy][npm-trademark].\n\nAdditionally, when choosing a name for an [**unscoped** package][create-unscoped], also choose a name that\n\n- is not already owned by someone else\n- is not spelled in a similar way to another package name\n- will not confuse others about authorship\n\n\n[policies]: https://www.npmjs.com/policies\n[npm-trademark]: https://www.npmjs.com/policies/trademark#the-npm-trademark-policy\n[create-unscoped]: creating-and-publishing-unscoped-public-packages\n"},{"id":"431e9df4-2a18-51a9-9f1b-84cb07f0d2ff","frontmatter":{"title":"Specifying dependencies and devDependencies in a package.json file"},"rawBody":"---\ntitle: Specifying dependencies and devDependencies in a package.json file\n---\n\nTo specify the packages your project depends on, you must\nlist them as `\"dependencies\"` or `\"devDependencies\"` in your package's [`package.json`][pkg-json] file. When you (or another user) run `npm install`, npm will download dependencies and devDependencies that are listed in `package.json` that meet the [semantic version][semver] requirements listed for each. To see which versions of a package will be installed, use the [semver calculator][semver-calc].\n\n- `\"dependencies\"`: Packages required by your application in production.\n- `\"devDependencies\"`: Packages that are only needed for local development and testing.\n\n## Adding dependencies to a `package.json` file\n\nYou can add dependencies to a `package.json` file from the command line or by manually editing the `package.json` file.\n\n### Adding dependencies to a `package.json` file from the command line\n\nTo add dependencies and devDependencies to a `package.json` file from the command line, you can install them in the root directory of your package using the `--save-prod` flag for dependencies (the default behavior of `npm install`) or the `--save-dev` flag for devDependencies.\n\nTo add an entry to the `\"dependencies\"` attribute of a `package.json` file, on the command line, run the following command:\n\n```\nnpm install [--save-prod]\n```\n\nTo add an entry to the `\"devDependencies\"` attribute of a `package.json` file, on the command line, run the following command:\n\n```\nnpm install --save-dev\n```\n\n### Manually editing the `package.json` file\n\nTo add dependencies to a `package.json` file, in a text editor, add an attribute called `\"dependencies\"` that references the name and [semantic version][semver] of each dependency:\n\n```\n{\n \"name\": \"my_package\",\n \"version\": \"1.0.0\",\n \"dependencies\": {\n \"my_dep\": \"^1.0.0\",\n \"another_dep\": \"~2.2.0\"\n }\n}\n```\n\nTo add devDependencies to a `package.json` file, in a text editor, add an attribute called `\"devDependencies\"` that references the name and [semantic version][semver] of each devDependency:\n\n```\n\"name\": \"my_package\",\n\"version\": \"1.0.0\",\n\"dependencies\": {\n \"my_dep\": \"^1.0.0\",\n \"another_dep\": \"~2.2.0\"\n},\n\"devDependencies\" : {\n \"my_test_framework\": \"^3.1.0\".\n \"another_dev_dep\": \"1.0.0 - 1.2.0\"\n}\n```\n\n[pkg-json]: creating-a-packge-json-file\n[semver]: about-semantic-versioning\n[semver-calc]: https://semver.npmjs.com/\n"},{"id":"86f67d67-59ed-5978-91b8-2abb00bd0462","frontmatter":{"title":"Downloading and installing packages globally"},"rawBody":"---\ntitle: Downloading and installing packages globally\nredirect_from:\n - /getting-started/installing-npm-packages-globally\n---\n\n\n\n**Tip:** If you are using npm 5.2 or higher, we recommend using `npx` to run packages globally.\n\n\n\n[Installing][cli-install] a package globally allows you to use the code in the package as a set of tools on your local computer.\n\nTo download and install packages globally, on the command line, run the following command:\n\n```\nnpm install -g \n```\n\nIf you get an EACCES permissions error, you may need to reinstall npm with a version manager or manually change npm's default directory. For more information, see \"[Resolving EACCES permissions errors when installing packages globally][perm-errors]\".\n\n\n[cli-install]: /cli/install\n[perm-errors]: resolving-eacces-permissions-errors-when-installing-packages-globally\n"},{"id":"731d5d33-7975-5aa7-80b1-7c30eefbf445","frontmatter":{"title":"Downloading and installing packages locally"},"rawBody":"---\ntitle: Downloading and installing packages locally\nredirect_from:\n - /downloading-and-installing-packages\n - /getting-started/installing-npm-packages-locally\n---\n\nYou can [install][cli-install] a package locally if you want to depend on the package from your own module, using something like Node.js `require`. This is `npm install`'s default behavior.\n\n## Installing an unscoped package\n\nUnscoped packages are always public, which means they can be searched for, downloaded, and installed by anyone. To install a public package, on the command line, run\n\n```\nnpm install \n```\n\nThis will create the `node_modules` directory in your current directory (if one doesn't exist yet) and will download the package to that directory.\n\n\n\n**Note:** If there is no `package.json` file in the local directory, the latest version of the package is installed.\n\nIf there is a `package.json` file, npm installs the latest version that satisfies the [semver rule](about-semantic-versioning) declared in `package.json`.\n\n\n\n## Installed a scoped public package\n\n[Scoped public packages][scoped-public-pkg] can be downloaded and installed by anyone, as long as the scope name is referenced during installation:\n\n```\nnpm install @scope/package-name\n```\n\n## Installing a private package\n\n[Private packages][private-pkg] can only be downloaded and installed by those who have been granted read access to the package. Since private packages are always scoped, you must reference the scope name during installation:\n\n```\nnpm install @scope/private-package-name\n```\n\n## Testing package installation\n\nTo confirm that `npm install` worked correctly, in your module directory, check that a `node_modules` directory exists and that it contains a directory for the package(s) you installed:\n\n```\nls node_modules\n```\n\n## Installed package version\n\nIf there is a `package.json` file in the directory in which `npm install` is run, npm installs the latest version of the package that satisfies the [semantic versioning rule][semver] declared in `package.json`.\n\nIf there is no `package.json` file, the latest version of the package is installed.\n\n## Installing a package with dist-tags\n\nLike `npm publish`, `npm install ` will use the `latest` tag by default.\n\nTo override this behavior, use `npm install @`. For example, to install the `example-package` at the version tagged with `beta`, you would run the following command:\n\n```\nnpm install example-package@beta\n```\n\n## Resources\n\n\n\n\n[scoped-public-pkg]: about-scopes\n[private-pkg]: about-private-packages\n[cli-install]: /cli-documentation/install\n[semver]: about-semantic-versioning\n"},{"id":"84e0994f-cac8-519c-bb23-29b12eef7d5a","frontmatter":{"title":"Getting packages from the registry"},"rawBody":"---\ntitle: Getting packages from the registry\n---\n\n\n\n"},{"id":"33219d4f-238c-5066-a1fe-8fb3d957961b","frontmatter":{"title":"Resolving EACCES permissions errors when installing packages globally"},"rawBody":"---\ntitle: Resolving EACCES permissions errors when installing packages globally\nredirect_from:\n - /getting-started/fixing-npm-permissions\n---\n\nIf you see an `EACCES` error when you try to [install a package globally][global-install], you can either:\n\n- Reinstall npm with a node version manager (recommended),\n\n **or**\n\n- Manually change npm's default directory\n\n## Reinstall npm with a node version manager\n\nThis is the best way to avoid permissions issues. To reinstall npm with a node version manager, follow the steps in \"[Downloading and installing Node.js and npm][install-npm]\". You do not need to remove your current version of npm or Node.js before installing a node version manager.\n\n## Manually change npm's default directory\n\n\n\n**Note:** This section does not apply to Microsoft Windows.\n\n\n\nTo minimize the chance of permissions errors, you can configure npm to use a different directory. In this example, you will create and use hidden directory in your home directory.\n\n1. Back up your computer.\n\n2. On the command line, in your home directory, create a directory for global installations:\n\n ```\n mkdir ~/.npm-global\n ```\n\n3. Configure npm to use the new directory path:\n\n ```\n npm config set prefix '~/.npm-global'\n ```\n\n4. In your preferred text editor, open or create a `~/.profile` file and add this line:\n\n ```\n export PATH=~/.npm-global/bin:$PATH\n ```\n\n5. On the command line, update your system variables:\n\n ```\n source ~/.profile\n ```\n\n6. To test your new configuration, install a package globally without using `sudo`:\n\n ```\n npm install -g jshint\n ```\n\nInstead of steps 2-4, you can use the corresponding ENV variable (e.g. if you don't want to modify `~/.profile`):\n\n```\nNPM_CONFIG_PREFIX=~/.npm-global\n```\n\n\n\n**npx: an alternative to running global commands**\n\nIf you are using npm version 5.2 or greater, you may want to consider [npx](https://www.npmjs.com/package/npx) as an alternative way to run global commands, especially if you only need a command occasionally. For more information, see [this article about npx](https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b).\n\n\n\n[global-install]: downloading-and-installing-packages-globally\n[install-npm]: downloading-and-installing-node-js-and-npm\n[npx]: https://www.npmjs.com/package/npx\n[npx-article]: https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b\n"},{"id":"522d1fa1-fe39-5e2e-941e-e24cdc81f4a3","frontmatter":{"title":"Searching for and choosing packages to download"},"rawBody":"---\ntitle: Searching for and choosing packages to download\nredirect_from:\n - /getting-started/searching-for-packages\n---\n\nYou can use the npm search bar to find packages to use in your projects. npm search uses npms and the npms analyzer; for more information on both, see https://npms.io/about.\n\n## Searching for a package\n\n1. In the search bar, type a search term and press **Enter**. As you type, possible choices will appear.\n\n \n \n\n2. To list packages ranked according to [package search rank criteria](#package-search-rank-criteria), in the left sidebar, under \"Sort packages\", click the criterion. For example, to sort packages by popularity, click \"Popularity\".\n\n3. In the package search results list, click the name of the package.\n\n## Package search rank criteria\n\nOften, there are dozens or even hundreds of packages with similar names and/or similar purposes. To help you decide the best ones to explore, each package has been ranked according to four criteria using the npms analyzer:\n\n### Popularity\n\nPopularity indicates how many times the package has been downloaded. This is a strong indicator of packages that others have found to be useful.\n\n### Quality\n\nQuality includes considerations such as the presence of a README file, stability, tests, up-to-date dependencies, custom website, and code complexity.\n\n### Maintenance\n\nMaintenance ranks packages according to the attention they are given by developers. More frequently maintained packages are more likely to work well with the current or upcoming versions of the npm CLI, for example.\n\n### Optimal\n\nOptimal combines the other three criteria (popularity, quality, maintenance) into one score in a meaningful way.\n"},{"id":"7d9d9535-012a-567c-8176-6c7b94ff4266","frontmatter":{"title":"Uninstalling packages and dependencies"},"rawBody":"---\ntitle: Uninstalling packages and dependencies\nredirect_from:\n - /getting-started/uninstalling-local-packages\n - /getting-started/uninstalling-global-packages\n---\n\nIf you no longer need to use a package in your code, we recommend uninstalling it and removing it from your project's dependencies.\n\n## Uninstalling local packages\n\n### Removing a local package from your node_modules directory\n\nTo remove a package from your node_modules directory, on the command line, use the [`uninstall` command][cli-uninstall]. Include the scope if the package is scoped.\n\nThis uninstalls a package, completely removing everything npm installed on its behalf.\n\nIt also removes the package from the dependencies, devDependencies, optionalDependencies, and peerDependencies objects in your package.json.\n\nFurther, if you have an npm-shrinkwrap.json or package-lock.json, npm will update those files as well.\n\n#### Unscoped package\n\n```\nnpm uninstall \n\n```\n\n#### Scoped package\n\n```\nnpm uninstall <@scope/package_name>\n```\n\n### Example\n\n```\nnpm uninstall lodash\n```\n\n### Removing a local package without removing it from package.json\n\nUsing the `--no-save` will tell npm not to remove the package from your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files.\n\n### Example\n\n```\nnpm uninstall --no-save lodash\n```\n\n\n\n`--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.\n\n\n\n### Confirming local package uninstallation\n\nTo confirm that `npm uninstall` worked correctly, check that the `node_modules` directory no longer contains a directory for the uninstalled package(s).\n\n- Unix system (such as OSX): `ls node_modules`\n- Windows systems: `dir node_modules`\n\n## Uninstalling global packages\n\nTo uninstall an unscoped global package, on the command line, use the `uninstall` command with the `-g` flag. Include the scope if the package is scoped.\n\n### Unscoped package\n\n```\nnpm uninstall -g \n```\n\n### Scoped package\n\n```\nnpm uninstall -g <@scope/package_name>\n```\n\n### Example\n\nFor example, to uninstall a package called `jshint`, run:\n\n```\nnpm uninstall -g jshint\n```\n\n## Resources\n\n### Uninstalling local packages\n\n\n\n### Uninstalling global packages\n\n\n\n\n[cli-uninstall]: /cli/uninstall\n"},{"id":"390e337e-8228-5443-a962-b4ef05b9c599","frontmatter":{"title":"Updating packages downloaded from the registry"},"rawBody":"---\ntitle: Updating packages downloaded from the registry\nredirect_from:\n - /getting-started/updating-local-packages\n - /getting-started/updating-global-packages\n---\n\nUpdating local and global packages you downloaded from the registry helps keep your code and tools stable, usable, and secure.\n\n## Updating local packages\n\nWe recommend regularly updating the local packages your project depends on to improve your code as improvements to its dependencies are made.\n\n1. Navigate to the root directory of your project and ensure it contains a `package.json` file:\n\n ```\n cd /path/to/project\n ```\n\n2. In your project root directory, run the [`update` command][npm-update]:\n\n ```\n npm update\n ```\n\n3. To test the update, run the [`outdated` command][npm-outdated]. There should not be any output.\n\n ```\n npm outdated\n ```\n\n## Updating globally-installed packages\n\n\n\n**Note:** If you are using npm version 2.6.0 or less, run [this script](https://gist.github.com/othiym23/4ac31155da23962afd0e) to update all outdated global packages.\n\nHowever, please consider upgrading to the latest version of npm:\n\n```\nnpm install npm@latest -g\n```\n\n\n\n### Determining which global packages need updating\n\nTo see which global packages need to be updated, on the command line, run:\n\n```\nnpm outdated -g --depth=0\n```\n\n### Updating a single global package\n\nTo update a single global package, on the command line, run:\n\n```\nnpm update -g \n```\n\n### Updating all globally-installed packages\n\nTo update all global packages, on the command line, run:\n\n```\nnpm update -g\n```\n\n## Resources\n\n\n\n### CLI commands\n\n- [npm-update](/cli/update)\n- [npm-outdated](/cli/outdated)\n\n\n[npm-update]: /cli/update\n[npm-outdated]: /cli/outdated\n"},{"id":"a2a0ad87-15c1-533a-b4b9-da7c74650bd0","frontmatter":{"title":"Using deprecated packages"},"rawBody":"---\ntitle: Using deprecated packages\n---\n\nIf you install a package, and it prints a deprecation message, we recommend following the instructions, if possible.\n\nThat might mean updating to a new version, or updating your package dependencies.\n\n\n\nA deprecation message doesn't always mean the package or version is unusable; it may mean the package is unmaintained and will no longer be updated by the publisher.\n"},{"id":"f2d08035-ab85-5ded-8de9-7c5379e530b3","frontmatter":{"title":"About public packages"},"rawBody":"---\ntitle: About public packages\n---\n\nAs an npm user or organization member, you can create and publish public packages that anyone can download and use in their own projects.\n\n* **Unscoped** public packages exist in the global public registry namespace and can be referenced in a `package.json` file with the package name alone: `package-name`.\n* **Scoped** public packages belong to a user or organization and must be preceded by the user or organization name when included as a dependency in a `package.json` file:\n * `@username/package-name`\n * `@org-name/package-name`\n\n## Next steps\n\n* \"[Creating and publishing scoped public packages][create-scoped-pkg]\"\n* \"[Creating and publishing unscoped public packages][create-unscoped-pkg]\"\n* \"[Using npm packages in your projects][use-pkg]\"\n\n\n[create-scoped-pkg]: creating-and-publishing-scoped-public-packages\n[create-unscoped-pkg]: creating-and-publishing-unscoped-public-packages\n[use-pkg]: using-npm-packages-in-your-projects\n"},{"id":"fe6412d3-c106-5594-9a4f-cfec15480ace","frontmatter":{"title":"About scopes"},"rawBody":"---\ntitle: About scopes\nredirect_from:\n - /getting-started/scoped-packages\n---\n\n
\n\nNote: You must be using npm version 2 or greater to use scopes. To upgrade to the latest version of npm, on the command line, run npm install npm@latest -g\n\n
\n\nWhen you sign up for an npm user account or create an organization, you are granted a scope that matches your user or organization name. You can use this scope as a namespace for related packages.\n\nA scope allows you to create a package with the same name as a package created by another user or organization without conflict.\n\nWhen listed as a dependent in a `package.json` file, scoped packages are preceded by their scope name. The scope name is everything between the `@` and the slash:\n\n* **\"npm\" scope:**\n```\n@npm/package-name\n```\n* **\"npmcorp\" scope:**\n```\n@npmcorp/package-name\n```\n\nTo create and publish public scoped packages, see \"[Creating and publishing scoped public packages][create-public-pkg]\".\n\nTo create and publish private scoped packages, see \"[Creating and publishing private packages][create-private-pkg]\".\n\n## Scopes and package visibility\n\n- Unscoped packages are always public.\n- [Private packages][about-priv-pkg] are always scoped.\n- Scoped packages are private by default; you must pass a command-line flag when publishing to make them public.\n\nFor more information on package scope and visibility, see \"[Package scope, access level, and visibility][pkg-viz]\".\n\n\n[create-public-pkg]: creating-and-publishing-scoped-public-packages\n[create-private-pkg]: creating-and-publishing-private-packages\n[about-priv-pkg]: about-private-packages\n[pkg-viz]: package-scope-access-level-and-visibility\n"},{"id":"a2192793-60a8-5837-9b0d-2ed914761f97","frontmatter":{"title":"About the public npm registry"},"rawBody":"---\ntitle: About the public npm registry\n---\n\nThe public npm registry is a database of JavaScript packages, each comprised of software and metadata. Open source developers and developers at companies use the npm registry to contribute packages to the entire community or members of their organizations, and download packages to use in their own projects.\n\nTo get started with the registry, [sign up for an npm account][signup] and check out the \"[Getting started][getting-started]\" and [CLI][cli] documentation.\n\n[public-website]: https://npmjs.com\n[cli]: /cli-documentation\n[signup]: https://www.npmjs.com/signup\n[getting-started]: /getting-started\n"},{"id":"588f6e3e-c67f-541c-8243-3817fbec39b9","frontmatter":{"title":"Introduction to packages and modules"},"rawBody":"---\ntitle: Introduction to packages and modules\n---\n\n\n\n"},{"id":"18e92413-ebe9-5c75-8443-2e1fd1061b53","frontmatter":{"title":"npm package scope, access level, and visibility"},"rawBody":"---\ntitle: npm package scope, access level, and visibility\n---\n\nVisibility of npm packages depends on the scope (namespace) in which the package is contained, and the access level (private or public) set for the package.\n\n
\n\nNote: To create organization-scoped packages, you must first create an organization. For more information, see \"Creating an organization\".\n\n
\n\n## Public registry\n\n| Scope | Access level | Can view and download | Can write (publish) |\n|--------------|--------------|-----------------------------------------------------------------------------|---|\n| Org | Private | Members of a team in the organization with read access to the package | Members of a team in the organization with read and write access to the package |\n| Org | Public | Everyone | Members of a team in the organization with read and write access to the package |\n| User | Private | The package owner and users who have been granted read access to the package | The package owner and users who have been granted read and write access to the package |\n| User | Public | Everyone | The package owner and users who have been granted read and write access to the package |\n| Unscoped | Public | Everyone | The package owner and users who have been granted read and write access to the package |\n\n
\n\nNote: Only user accounts can create and manage unscoped packages. Organizations can only manage scoped packages.\n\n
\n"},{"id":"d1e4838e-50e0-5cc8-a0ac-dd7f44423237","frontmatter":{"title":"About audit reports"},"rawBody":"---\ntitle: About audit reports\n---\n\n# About audit reports\n\nAudit reports contain tables of information about security vulnerabilities in your project's dependencies to help you fix the vulnerability or troubleshoot further.\n\n\n\n## Vulnerability table fields\n\n* [Severity](#severity)\n* [Description](#description)\n* [Package](#package)\n* [Patched in](#patched-in)\n* [Dependency of](#dependency-of)\n* [Path](#path)\n* [More info](#more-info)\n\n### Severity\n\nThe severity of the vulnerability, determined by the impact and exploitability of the vulnerability in its most common use case.\n\n| Severity | Recommended action |\n|:---------|:--------------------|\n| Critical | Address immediately |\n| High | Address as quickly as possible |\n| Moderate | Address as time allows |\n| Low | Address at your discretion |\n\n#### Description\nThe description of the vulnerability. For example, \"Denial of service\".\n\n#### Package\nThe name of the package that contains the vulnerability.\n\n#### Patched in\nThe semantic version range that describes which versions contain a fix for the vulnerability.\n\n#### Dependency of\nThe module that the package with the vulnerability depends on.\n\n#### Path\nThe path to the code that contains the vulnerability.\n\n#### More info\nA link to the security report.\n"},{"id":"5c502cd6-8abd-5a51-a247-d7dc53560527","frontmatter":{"title":"About PGP registry signatures (deprecated)"},"rawBody":"---\ntitle: About PGP registry signatures (deprecated)\n---\n\n\n**Note:** PGP signatures will be deprecated early 2023, in favour of ECDSA registry signatures that can be verified using the npm CLI. [Learn more.](/about-registry-signatures)\n\n\n\nTo increase confidence in the npm public registry, we add our [PGP][pgp-wiki] signature to package metadata and publicize our public PGP key on [Keybase][keybase]. Our Keybase account is \"[npmregistry][npmregistry]\" and our public PGP key can be found at https://keybase.io/npmregistry/pgp_keys.asc\n\nYou can use the package PGP signature and our public PGP key to verify that the same entity who published the key (npm) also signed the package you downloaded from the npm public registry. For more information, see \"[Verifying the PGP signature of a package from the npm public registry][verify-pgp]\".\n\n## Tools we use\n\n### openpgpjs\n\nTo generate PGP signatures, we use [openpgpjs][openpgpjs-repo], a pure JavaScript implementation of OpenPGP. To learn more about openpgpjs, see https://openpgpjs.org/.\n\n### Keybase\n\nWe use Keybase to publicize our PGP key and give you confidence that the npm registry you install from is the same registry that signs packages.\n\nKeybase offers two advantages over the core OpenPGP experience that move us to recommend it to you:\n\n- The Keybase application and CLI provide an excellent user experience for PGP, which can be intimidating for newcomers.\n- Keybase manages and displays social proofs that the entity that controls a specific PGP key also controls accounts on social media and other places. These proofs help you determine whether you can trust an account.\n\nWe’ve established proofs on Keybase that we control [@npmjs][npmjs-twitter] on Twitter, the domain [npmjs.com][npmjs-com], and the domain [npmjs.org][npmjs-org]. Verifying these proofs won’t tell you who owns those domains, but it does establish that the same entity controls them, and the PGP key advertised on Keybase.\n\nIf you install Keybase and create an account, you can follow npmregistry yourself and obtain a local copy of the registry’s public key. For more information, and to verify the PGP signature of a specific package version from the npm public registry, see \"[Verifying the PGP signature for a package from the npm public registry][verify-pgp]\".\n\n\n[keybase]: https://keybase.io\n[pgp-wiki]: https://en.wikipedia.org/wiki/Pretty_Good_Privacy\n[npmregistry]: https://keybase.io/npmregistry\n[openpgpjs-repo]: https://github.com/openpgpjs/openpgpjs\n[npmjs-twitter]: https://twitter.com/npmjs\n[npmjs-com]: https://npmjs.com\n[npmjs-org]: https://npmjs.org\n[verify-pgp]: verifying-the-pgp-signature-for-a-package-from-the-npm-public-registry\n"},{"id":"b2c7655d-db30-5b11-9e5f-09c1363a541f","frontmatter":{"title":"About ECDSA registry signatures"},"rawBody":"---\ntitle: About ECDSA registry signatures\n---\n\nPackages published to the public npm registry are signed to make it possible to detect if the package content has been tampered with.\n\nSigning and verifying published packages protects against an attacker controlling a registry mirror or proxy where they attempt to intercept and tamper with the package tarball content.\n\n## Migrating from PGP to ECDSA signatures\n\n\n\n**Note:** PGP signatures will be deprecated early 2023, in favour of ECDSA registry signatures. More information will soon be provided.\n\n\n\nThe public npm registry is migrating away from the existing PGP signatures to ECDSA signatures that are more compact and can be verified without extra dependencies in the npm CLI.\n\nSignature verification was previously a multi-step process involving the Keybase CLI, as well as manually retrieving and parsing the signature from the package metadata.\n\nRead more about migrating and verifying signatures using the npm CLI.\n\n## Supporting signatures on third-party registries\n\nThe npm CLI supports registry signatures and signing keys provided by any registry if the following conventions are followed:\n\n**1. Signatures are provided in the package's `packument` in each published version within the `dist` object:**\n\n ```\n \"dist\":{\n ..omitted..,\n \"signatures\": [{\n \"keyid\": \"SHA256:{{SHA256_PUBLIC_KEY}}\",\n \"sig\": \"a312b9c3cb4a1b693e8ebac5ee1ca9cc01f2661c14391917dcb111517f72370809...\"\n }],\n ```\n\nSee this example of a signed package from the public npm registry.\n\nTo generate the signature, sign the package name, version and tarball sha integrity: `${package.name}@${package.version}:${package.dist.integrity}`.\n\nThe current best practice is to use a Key Management System that does the signing operation on a Hardware Security Module (HSM) in order to not directly handle the private key part, which reduces the attack surface.\n\nThe `keyid` must match one of the public signing keys below.\n\n**2. Public signing keys are provided at `registry-host.tld/-/npm/v1/keys` in the following format:**\n\n ```\n {\n \"keys\": [{\n \"expires\": null,\n \"keyid\": \"SHA256:{{SHA256_PUBLIC_KEY}}\",\n \"keytype\": \"ecdsa-sha2-nistp256\",\n \"scheme\": \"ecdsa-sha2-nistp256\",\n \"key\": \"{{B64_PUBLIC_KEY}}\"\n }]\n }\n ```\n\nKeys response:\n\n- `expires`: null or a simplified extended ISO 8601 format: `YYYY-MM-DDTHH:mm:ss.sssZ`\n- `keydid`: sha256 fingerprint of the public key\n- `keytype`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI\n- `scheme`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI\n- `key`: base64 encoded public key\n\nSee this example key's response from the public npm registry.\n"},{"id":"09c9e0ae-17d2-5e46-a753-97df56082d3a","frontmatter":{"title":"Auditing package dependencies for security vulnerabilities"},"rawBody":"---\ntitle: Auditing package dependencies for security vulnerabilities\nredirect_from:\n - /getting-started/running-a-security-audit/\n---\n\n## About security audits\n\nA security audit is an assessment of package dependencies for security vulnerabilities. Security audits help you protect your package's users by enabling you to find and fix known vulnerabilities in dependencies that could cause data loss, service outages, unauthorized access to sensitive information, or other issues.\n\n## Running a security audit with `npm audit`\n\n\n\n**Note:** The `npm audit` command is available in npm@6. To upgrade, run `npm install npm@latest -g`.\n\n\n\nThe `npm audit` command submits a description of the dependencies configured in your package to your default registry and asks for a report of known vulnerabilities. `npm audit` checks direct dependencies, devDependencies, bundledDependencies, and optionalDependencies, but does not check peerDependencies.\n\n`npm audit` automatically runs when you install a package with `npm install`. You can also run `npm audit` manually on your [locally installed packages](downloading-and-installing-packages-locally) to conduct a security audit of the package and produce a report of dependency vulnerabilities and, if available, suggested patches.\n\n1. On the command line, navigate to your package directory by typing `cd path/to/your-package-name` and pressing **Enter**.\n2. Ensure your package contains `package.json` and `package-lock.json` files.\n3. Type `npm audit` and press **Enter**.\n4. Review the audit report and run recommended commands or investigate further if needed.\n\n### Resolving `EAUDITNOPJSON` and `EAUDITNOLOCK` errors\n\n`npm audit` requires packages to have `package.json` and `package-lock.json` files.\n\n* If you get an `EAUDITNOPJSON` error, create a `package.json` file by following the steps in \"[Creating a package.json file](creating-a-package-json-file)\".\n* If you get an `EAUDITNOLOCK` error, make sure your package has a `package.json` file, then create the package lock file by running `npm i --package-lock-only`.\n\n## Reviewing and acting on the security audit report\n\nRunning `npm audit` will produce a report of security vulnerabilities with the affected package name, vulnerability severity and description, path, and other information, and, if available, commands to apply patches to resolve vulnerabilities. For more information on the fields in the audit report, see \"[About audit reports](about-audit-reports)\"\n\n### Security vulnerabilities found with suggested updates\n\nIf security vulnerabilities are found and updates are available, you can either:\n\n* Run the `npm audit fix` subcommand to automatically install compatible updates to vulnerable dependencies.\n* Run the recommended commands individually to install updates to vulnerable dependencies. (Some updates may be semver-breaking changes; for more information, see \"[SEMVER warnings](#semver-warnings)\".)\n\n\n\n#### SEMVER warnings\n\nIf the recommended action is a potential breaking change (semantic version major change), it will be followed by a `SEMVER WARNING` that says \"SEMVER WARNING: Recommended action is a potentially breaking change\". If the package with the vulnerability has changed its API, you may need to make additional changes to your package's code.\n\n### Security vulnerabilities found requiring manual review\n\nIf security vulnerabilities are found, but no patches are available, the audit report will provide information about the vulnerability so you can investigate further.\n\n\n\nTo address the vulnerability, you can\n\n* [Check for mitigating factors](#check-for-mitigating-factors)\n* [Update dependent packages if a fix exists](#update-dependent-packages-if-a-fix-exists)\n* [Fix the vulnerability](#fix-the-vulnerability)\n* [Open an issue in the package or dependent package issue tracker](#open-an-issue-in-the-package-or-dependent-package-issue-tracker)\n\n#### Check for mitigating factors\n\nReview the security advisory in the \"More info\" field for mitigating factors that may allow you to continue using the package with the vulnerability in limited cases. For example, the vulnerability may only exist when the code is used on specific operating systems, or when a specific function is called.\n\n#### Update dependent packages if a fix exists\n\nIf a fix exists but packages that depend on the package with the vulnerability have not been updated to include the fixed version, you may want to open a pull or merge request on the dependent package repository to use the fixed version.\n\n1. To find the package that must be updated, check the \"Path\" field for the location of the package with the vulnerability, then check for the package that depends on it. For example, if the path to the vulnerability is `@package-name > dependent-package > package-with-vulnerability`, you will need to update `dependent-package`.\n2. On the [npm public registry](https://npmjs.com), find the dependent package and navigate to its repository. For more information on finding packages, see \"[Searching for and choosing packages to download](searching-for-and-choosing-packages-to-download)\".\n3. In the dependent package repository, open a pull or merge request to update the version of the vulnerable package to a version with a fix.\n4. Once the pull or merge request is merged and the package has been updated in the [npm public registry](https://npmjs.com), update your copy of the package with `npm update`.\n\n#### Fix the vulnerability\n\nIf a fix does not exist, you may want to suggest changes that address the vulnerability to the package maintainer in a pull or merge request on the package repository.\n\n1. Check the \"Path\" field for the location of the vulnerability.\n2. On the [npm public registry](https://npmjs.com), find the package with the vulnerability. For more information on finding packages, see \"[Searching for and choosing packages to download](searching-for-and-choosing-packages-to-download)\".\n3. In the package repository, open a pull or merge request to make the fix on the package repository.\n4. Once the fix is merged and the package has been updated in the npm public registry, update your copy of the package that depends on the package with the fix.\n\n#### Open an issue in the package or dependent package issue tracker\n\nIf you do not want to fix the vulnerability or update the dependent package yourself, open an issue in the package or dependent package issue tracker.\n\n1. On the [npm public registry](https://npmjs.com), find the package with the vulnerability or the dependent package that needs an update. For more information on finding packages, see \"[Searching for and choosing packages to download](searching-for-and-choosing-packages-to-download)\".\n2. In the package or dependent package issue tracker, open an issue and include information from the audit report, including the vulnerability report from the \"More info\" field.\n\n### No security vulnerabilities found\n\nIf no security vulnerabilities are found, this means that packages with known vulnerabilities were not found in your package dependency tree. Since the advisory database can be updated at any time, we recommend regularly running `npm audit` manually, or adding `npm audit` to your continuous integration process.\n\n\n\n## Turning off `npm audit` on package installation\n\n### Installing a single package\n\nTo turn off `npm audit` when installing a single package, use the `--no-audit` flag:\n\n```\nnpm install example-package-name --no-audit\n```\n\nFor more information, see the [`npm-install` command][cli-install].\n\n### Installing all packages\n\nTo turn off `npm audit` when installing all packages, set the `audit` setting to `false` in your user and global npmrc config files:\n\n```\nnpm set audit false\n```\n\nFor more information, see the [`npm-config` management command][cli-config] and the [`npm-config` audit setting][cli-config-audit].\n\n\n[cli-install]: /cli/install\n[cli-config]: /cli/config\n[cli-config-audit]: /cli/config#audit\n"},{"id":"d27213fb-a92e-5cb5-a94c-68f75a86e15c","frontmatter":{"title":"Securing your code"},"rawBody":"---\ntitle: Securing your code\n---\n\n\n\n"},{"id":"0b2dcdcd-ffc7-5608-8ca3-f042c3444e0a","frontmatter":{"title":"Reporting malware in an npm package"},"rawBody":"---\ntitle: Reporting malware in an npm package\nredirect_from:\n - /reporting-a-vulnerability-in-an-npm-package\n---\n\nIf you find malware in an npm package (either yours or someone else's), you can report it to the npm Security team to help keep the Javascript ecosystem safe.\n\n\n\n**Note:** Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with `npm owner ls `. If the source code is hosted on GitHub please refer to the repository's [Security Policy](https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository#about-security-policies).\n\n\n\n## How npm Security handles malware\n\nMalware is a major concern for npm Security and we have removed hundreds of malicious packages from the registry. For every malware report we receive, npm Security takes the following actions:\n1. Confirm validity of the report.\n2. Remove the package from the registry.\n3. Publish a security placeholder for the package.\n4. Publish a security advisory alerting the community.\n\nAs part of our process we determine whether the user account who uploaded the package should be banned. We also cooperate with 3rd parties when applicable.\n\n## Reporting malware\n\n1. Gather information about the malware.\n2. On the package page, click **Report malware**.\n3. On the malware report page, provide information about yourself and the malware:\n - **Name:** Your name.\n - **Email address:** An email address the npm Security team can use to contact you.\n - **Package name:** The name of the package that contains the malware.\n - **Package version:** The version of the package that contains the malware. Include all affected versions.\n - **Description of the malware:** A brief description of the malware and its effects. Include references, commits, and/or code examples that would help our researchers confirm the report.\n4. Click **Send Report**.\n"},{"id":"a3757046-836d-539b-8aff-c744bd263483","frontmatter":{"title":"Requiring 2FA for package publishing and settings modification"},"rawBody":"---\ntitle: Requiring 2FA for package publishing and settings modification\n---\nimport shared from '../../../src/shared.js'\n\nTo protect your packages, as a package publisher, you can require everyone who has write access to a package to have two-factor authentication (2FA) enabled. This will require that users provide 2FA credentials in addition to their login token when they publish the package. For more information, see \"[Configuring two-factor authentication][config-2fa]\".\n\nYou may also choose to allow publishing with either two-factor authentication _or_ with [automation tokens][creating-tokens]. This lets you configure automation tokens in a CI/CD workflow, but requires two-factor authentication from interactive publishes.\n\n## Configuring two-factor authentication\n\n1. <>{shared['user-login'].text}\n\n <>{shared['user-login'].image}\n\n2. Navigate to the package on which you want to require a second factor to publish or modify settings.\n\n3. Click **Settings**.\n\n \n\n4. Under \"Publishing access\", select the requirements to publish a package.\n 1. **Two-factor authentication is not required** \n With this option, a maintainer can publish a package or change the package settings whether they have two-factor authentication enabled or not. This is the least secure setting.\n\n 2. **Require two-factor authentication or automation tokens** \n With this option, maintainers must have two-factor authentication enabled for their account. If they publish a package interactively, using the `npm publish` command, they will be required to enter 2FA credentials when they perform the publish. However, maintainers may also create an [automation token][creating-tokens] and use that to publish. A second factor is _not_ required when using an automation token, making it useful for continuous integration and continuous deployment workflows.\n\n 3. **Two-factor authentication only** \n With this option, a maintainer must have two-factor authentication enabled for their account, and they must publish interactively. Maintainers will be required to enter 2FA credentials when they perform the publish.\n\n \n\n5. Click **Update Package Settings**.\n\n \n\n[config-2fa]: configuring-two-factor-authentication\n[creating-tokens]: creating-and-viewing-access-tokens\n"},{"id":"3d80def4-6d17-5ed6-b57c-ba3ae046509e","frontmatter":{"title":"Verifying ECDSA registry signatures"},"rawBody":"---\ntitle: Verifying ECDSA registry signatures\n---\n\nTo ensure the integrity of packages you download from the public npm registry, or any registry that supports signatures, you can verify the registry signatures of downloaded packages using the npm CLI.\n\n## Prerequisites\n\n1. Install npm CLI version v8.15.0 or later\n2. Install dependencies using `npm install` or `npm ci`\n\n## Verifying registry signatures\n\nRegistry signatures can be verified using the following `audit` command:\n\n ```\n npm audit signatures\n ```\n\nExample response if all installed versions have valid registry signatures:\n\n ```\n audited 1640 packages in 2s\n\n 1640 have verified registry signatures\n ```\n\n## Troubleshooting\n\n### Some packages are missing registry signatures\n\nThe CLI will error if packages don't have signatures *and* if the package registry supports signatures. This could mean an attacker might be trying to circumvent signature verification.\nYou can check if the registry supports signatures by requesting the public signing keys from `registry-host.tld/-/npm/v1/keys`.\n\nExample response if some versions have missing registry signatures:\n\n ```\n audited 1640 packages in 2s\n\n 1405 packages have verified registry signatures\n\n 235 packages have missing registry signatures but the registry is providing signing keys:\n\n missing-dep@1.0.0 (https://registry.npmjs.org/)\n ...\n ```\n"},{"id":"b0617300-f370-5245-8e18-7b3f074ec5ad","frontmatter":{"title":"Verifying the PGP registry signature of a package from the npm public registry (deprecated)"},"rawBody":"---\ntitle: Verifying the PGP registry signature of a package from the npm public registry (deprecated)\n---\n\n\n\n**Note:** PGP signatures will be deprecated early 2023, in favour of ECDSA registry signatures that can be verified using the npm CLI. More information will soon be provided.\n\n\n\nTo ensure the integrity of a package version you download from the npm public registry, you can manually verify the [PGP signature][about-pgp-sig] of the package.\n\n\n\n**Note:** Since fully verifying signatures on Keybase requires rechecking proofs (which requires network activity) and is therefore expensive, we recommend only verifying signatures if it is necessary -- for example, when verifying a deploy artifact, or when initially storing a package in your cache.\n\n\n\n## Prerequisites\n\n1. Install Keybase from https://keybase.io/download\n2. Create a Keybase account on https://keybase.io\n3. Follow \"[npmregistry][npmregistry]\" on Keybase.\n4. Download a local copy of the npm public registry's [public PGP key][npm-key].\n\n## Verifying npm signatures for the public registry\n\n\n\n**Note:** The following steps use version 1.4.3 of the `light-cycle` package as an example.\n\n\n\n1. On the command line, fetch the signature for the package version you want and save it in a file:\n\n ```\n npm view light-cycle@1.4.3 dist.npm-signature > sig-to-check\n ```\n\n2. Get the integrity field for that version (example below includes response):\n\n ```\n npm view light-cycle@1.4.3 dist.integrity\n ```\n\n Example response:\n\n ```\n sha512-sFcuivsDZ99fY0TbvuRC6CDXB8r/ylafjJAMnbSF0y4EMM1/1DtQo40G2WKz1rBbyiz4SLAc3Wa6yZyC4XSGOQ==\n ```\n\n3. Construct the string that ties the unique package name and version to the integrity string (example below includes response):\n\n ```\n keybase pgp verify --signed-by npmregistry -d sig-to-check -m 'light-cycle@1.4.3:sha512-sFcuivsDZ99fY0TbvuRC6CDXB8r/ylafjJAMnbSF0y4EMM1/1DtQo40G2WKz1rBbyiz4SLAc3Wa6yZyC4XSGOQ=='\n ```\n\n Example response:\n\n ```\n ▶ INFO Identifying npmregistry\n ✔ public key fingerprint: 0963 1802 8A2B 58C8 4929 D8E1 3D4D 5B12 0276 566A\n ✔ admin of DNS zone npmjs.org: found TXT entry keybase-site-verification=Ls8jN55i6KesjiX91Ck79bUZ17eA-iohmw2jJFM16xc\n ✔ admin of DNS zone npmjs.com: found TXT entry keybase-site-verification=iK3pjpRBkv-CIJ4PHtWL4TTcFXMpPiwPynatKl3oWO4\n ✔ \"npmjs\" on twitter: https://twitter.com/npmjs/status/981288548845240320\n Signature verified. Signed by npmregistry 3 years ago (2018-04-13 15:00:37 -0700 MST).\n PGP Fingerprint: 096318028a2b58c84929d8e13d4d5b120276566a.\n ```\n\n[about-pgp-sig]: about-pgp-signatures-for-packages-in-the-public-registry\n[keybase]: https://keybase.io\n[npmregistry]: https://keybase.io/npmregistry\n[npm-key]: https://keybase.io/npmregistry/pgp_keys.asc\n"},{"id":"1265aeaa-28ed-5446-9fb3-e272db6bd62b","frontmatter":{"title":"Adding collaborators to private packages owned by a user account"},"rawBody":"---\ntitle: Adding collaborators to private packages owned by a user account\n---\n\nAs an npm user with a paid user account, you can add another npm user with a paid account as a collaborator on a private package you own.\n\n\n\n**Note:** The user you want to add as a collaborator on your private package must have a paid user account. To sign up for a paid account, they can visit `https://www.npmjs.com/settings/username/billing`, replacing `username` with their npm username.\n\n\n\nWhen you add a member to your package, they are sent an email inviting them to the package. The new member has to accept the invitation gain access to the package.\n\n## Granting access to a private user package on the web\n\n1. On the [npm website][npmjs-com], go to the package to which you want to add a collaborator: `https://www.npmjs.com/package/`\n2. On the package page, under \"Collaborators\", click **+**.\n3. Enter the npm username of the collaborator.\n4. Click **Submit**.\n\n## Granting private package access from the command line interface\n\nTo add a collaborator to a package on the command line, run the following command, replacing `` with the npm username of your collaborator, and `` with the name of the private package:\n\n```\nnpm owner add \n```\n\n## Granting access to private organization packages\n\nTo grant an npm user access to private organization packages, you must have an organization owner add them to your organization, then add them to a team that has access to the private package. For more information, see \"[Adding members to your organization][add-org-members]\".\n\n[npmjs-com]: https://npmjs.com\n[add-org-members]: adding-members-to-your-organization\n"},{"id":"a6083216-2841-536c-aaa7-7148adf05d82","frontmatter":{"title":"Changing package visibility"},"rawBody":"---\ntitle: Changing package visibility\n---\n\nYou can change the visibility of a scoped package from the website or command line.\n\nYou must be the owner of the user account or organization that owns the package in order to change package visibility.\n\nFor more information about package visibility, see \"[Package scope, access level, and visibility][pkg-viz]\".\n\n\n\n**Note:** You cannot change the visibility of an unscoped package. Only scoped packages with a paid subscription may be private.\n\n\n\n## Making a public package private\n\n\n\n**Note:** Making a package private requires a paid user account or organization. To sign up for a paid user or organization, go to `https://www.npmjs.com/settings/account-name/billing`, replacing `account-name` with the name of your npm user account or organization.\n\n\n\nIf you want to restrict access and visibility for a public package you own, you can make the package private. When you make a package private, its access will be updated immediately and it will be removed from the website within a few minutes of the change.\n\n### Using the website\n\n1. On the [npm website][npmjs-com], go to the package page.\n2. On the package page, click **Admin**.\n3. Under \"Package Access\", select \"Is Package Private?\"\n4. Click **Update package settings**.\n\n### Using the command line\n\nTo make a public package private on the command line, run the following command, replacing `` with the name of your package:\n\n```\nnpm access restricted \n```\n\nFor more information, see the `npm access` documentation.\n\n## Making a private package public\n\n
\n\nNote: When you make a private package public, the package will be visible to and downloadable by all npm users.\n\n
\n\n### Using the website\n\n1. On the npm website, go to the package page.\n2. On the package page, click **Admin**.\n3. Under \"Package Access\", deselect \"Is Package Private?\"\n4. Click **Update package settings**.\n\n### Using the command line\n\nTo make a private package public on the command line, run the following command, replacing `` with the name of your package:\n\n```\nnpm access public \n```\n\nFor more information, see the [`npm access` CLI documentation][access-cli].\n\n\n[contact-support]: https://www.npmjs.com/support\n[pkg-viz]: package-scope-access-level-and-visibility\n[npmjs-com]: https://npmjs.com\n[access-cli]: /cli/access\n"},{"id":"ee828cfa-7b56-5963-8ded-42c3abc81e10","frontmatter":{"title":"Deprecating and undeprecating packages or package versions"},"rawBody":"---\ntitle: Deprecating and undeprecating packages or package versions\n---\nimport shared from '../../../src/shared.js'\n\nIf you no longer wish to maintain a package, or if you would like to encourage users to update to a new or different version, you can [deprecate][deprecate-cli] it. Deprecating a package or version will print a message to the terminal when a user installs it.\n\nA deprecation warning or message can say anything. You may wish to include a message encouraging users to update to a specific version, or an alternate, supported package.\n\n\n\n**Note:** We strongly recommend deprecating packages or package versions instead of unpublishing them, because unpublishing removes a package from the registry entirely, meaning anyone who relied on it will no longer be able to use it, with no warning.\n\n\n\n## Deprecating an entire package\n\nDeprecating an entire package will remove it from search results on the\nnpm website and a deprecation message will also be displayed on the\npackage page.\n\n\n\nDeprecating a package is an alternative to deleting a package if\nyour package does not meet the\n[unpublishing requirements](/policies/unpublish).\n\n### Using the website\n\n1. <>{shared[\"user-login\"].text}\n\n <>{shared[\"user-login\"].image}\n\n2. Navigate to the package page for the package you want to deprecate, replacing `` with the name of your package:\n `https://www.npmjs.com/package/`.\n\n3. Click **Settings**.\n \n\n4. Under \"deprecate package\", click Deprecate package.\n\n\t\n\n5. If you are sure that you want to continue, enter your package name and click Deprecate package.\n\n\t\n\n### Using the command line\n\nTo deprecate an entire package, run the following command, replacing `` with the name of your package, and `\"\"` with your deprecation message:\n\n```\nnpm deprecate \"\"\n```\n\nIf you have enabled [two-factor authentication][two-factor-auth], add a one-time password to the command, `--otp=123456` (where *123456* is the code from your authenticator app).\n\n## Deprecating a single version of a package\n\nWhen you deprecate a version of a package, a red message will be displayed on that version's package page, similar to deprecating an entire package.\n\n\n\n### Using the command line\n\nTo deprecate a package version, run the following command, replacing `` with the name of your package, `` with your version number, and `\"\"` with your deprecation message:\n\n```\nnpm deprecate @ \"\"\n```\n\nThe CLI will also accept version ranges for ``.\n\nIf you have two-factor auth, add a one-time password to the command, `--otp=123456` (where *123456* is the code from your authenticator).\n\n## Undeprecating a package or version\n\nTo undeprecate a package, replace `\"\"` with `\"\"` (an empty string) in one of the above commands.\n\nFor example, to undeprecate a package version, run the following command, replacing `` with the name of your package, and `` with your version number:\n\n```\nnpm deprecate @ \"\"\n```\n\nIf you have two-factor auth, add a one-time password to the command, `--otp=123456` (where *123456* is the code from your authenticator).\n\n## Transferring a deprecated package to npm\n\nIf you are no longer maintaining a package, but other users depend on it, and you'd like to remove it from your user profile, you can transfer it to the [`@npm`][npm-account] user account, which is owned by the npm registry.\n\n\n\n**Note:** Once you transfer a package to the npm account, you will no longer be able to update it.\n\n\n\nTo transfer a package to the npm user account, run the following two commands in order, replacing `` with your npm user name, and `` with the package you want to transfer:\n\n```\nnpm owner add npm \nnpm owner rm \n```\n\nIf you have two-factor auth, add a one-time password to the command, `--otp=123456` (where *123456* is the code from your authenticator).\n\n[deprecate-cli]: /cli/deprecate\n[two-factor-auth]: about-two-factor-authentication\n[npm-account]: https://www.npmjs.com/~npm\n"},{"id":"bae3e6a3-91bf-5d92-b195-f8158b88b73e","frontmatter":{"title":"Updating and managing your published packages"},"rawBody":"---\ntitle: Updating and managing your published packages\n---\n\n\n\n"},{"id":"f436305c-225a-5ed4-b464-fdb7f7d9b8c5","frontmatter":{"title":"Transferring a package from a user account to another user account"},"rawBody":"---\ntitle: Transferring a package from a user account to another user account\n---\n\nAs a package owner or maintainer, you can transfer ownership of a package you no longer wish to maintain to another trusted npm user using either the npm website or the command line.\n\nFor more information on how npm support handles package name disputes between users, you can refer to npm's [package name dispute policy][dispute-policy].\n\n\n\n**Note:** You cannot transfer a scoped package to another user account or organization, because a package's scope _is_ the user account or organization name. You will need to create a new package in the new scope.\n\n\n\n## Transferring a package from a user account to another user account on the website\n\nTo transfer a package you own or maintain to another user, follow these steps: \n\n1. Navigate to the package page for the package you want to transfer, replacing `` with the name of your package:\n`https://www.npmjs.com/package/`.\n\n2. On the package Admin tab, under \"Maintainers\", enter the npm username of the new maintainer.\n\n \n\n3. Click \"Invite.\"\n\n4. To remove yourself as a maintainer, under the maintainers list, click the \"x\" next to your username.\n\n \n\n## Transferring a package from a user account to another user account on the command line\n\nTo transfer a package to another npm user using the CLI, run the [`npm owner add`][npm-owner] command replacing `` with the other user's npm username. An email invitation is sent to the other user. After the user has accepted the invitation, run the `npm owner rm` command replacing `` with your npm username:\n\n```\nnpm owner add \n\n# new maintainer accepts invitation\n\nnpm owner rm \n```\n\nIf you have two-factor authentication enabled for writes, add a one-time password to the command, `--otp=123456` (where *123456* is the code from your authenticator application).\n\n```\nnpm owner add --otp=123456\n\n# new maintainer accepts invitation\n\nnpm owner rm --otp=123456\n```\n\n[dispute-policy]: /policies/disputes\n[npm-owner]: cli/owner\n"},{"id":"8d1238b7-7bde-59b2-b084-f731213b0bad","frontmatter":{"title":"Unpublishing packages from the registry"},"rawBody":"---\ntitle: Unpublishing packages from the registry\n---\nimport shared from '../../../src/shared.js'\n\nAs a package owner or collaborator, if your package has no dependents, you can permanently remove it from the npm registry by using the CLI. You can [unpublish](https://docs.npmjs.com/cli/v7/commands/npm-unpublish) within 72 hours of the initial publish; beyond 72 hours, you can still unpublish your package if [it meets certain criteria](https://www.npmjs.com/policies/unpublish).\n\nThese criteria are set to avoid damaging the JavaScript package ecosystem. If you cannot unpublish your package, you can [deprecate it instead](/deprecating-and-undeprecating-packages-or-package-versions).\n\n\n\n**Note:** Removing all the collaborators or teams from the package will not unpublish it.\n\n\n\n## Unpublishing a package\n\nIf you want to completely remove all versions of a package from the registry, you can unpublish it completely. This will delete it from the registry and it will be unable to be installed.\n\nTo unpublish a package, you must meet the requirements of the [package unpublishing rules](#how-to-unpublish).\n\n### Using the website\n\n1. <>{shared[\"user-login\"].text}\n\n <>{shared[\"user-login\"].image}\n\n2. Navigate to the package page for the package you want to unpublish, replacing `` with the name of your package:\n `https://www.npmjs.com/package/`.\n\n3. Click **Settings**.\n \n\n4. Under \"delete package\", click Delete package.\n\n\t\n\n \n\n **Note:** If you cannot delete the package because it does not meet the [unpublishing requirements](#how-to-unpublish), then the delete package option will not be available. Instead, you will be prompted to [deprecate the package](/deprecating-and-undeprecating-packages-or-package-versions#deprecating-a-package-from-the-website).\n\n \n\n5. If you are sure that you want to continue, enter your package name and click Delete package.\n\n\t\n\n### Using the command line\n\nTo unpublish an entire package, run the following command, replacing `` with the name of your package:\n\n```\nnpm unpublish -f\n```\n\nIf you have [two-factor authentication][two-factor-auth] enabled for writes, you will need to add a one-time password to the `unpublish` command, `--otp=123456` (where *123456* is the code from your authenticator app).\n\n<>If you need help unpublishing your package, please {shared['contact-support'].text}. If you are an Enterprise customer, please {shared['contact-enterprise-support'].text}.\n\n\n\n**Note:** If you unpublish an entire package, you may not publish any new versions of that package until 24 hours have passed.\n\n\n\n## Unpublishing a single version of a package\n\nIf you want to remove a single version of a package, you can unpublish one version without affecting the others. This will delete only that version from the registry and it will be unable to be installed. This option is only available via the npm CLI.\n\n### Using the command line\n\nTo unpublish a single version of a package, run the following command, replacing `` with the name of your package, and `` with your version number:\n\n```\nnpm unpublish @\n```\n\n## When to unpublish\n\nUnpublishing a package permanently removes the package from the registry so it is no longer available for other users to install. Once a package is unpublished, republishing under the same name is blocked for 24 hours. If you've unpublished a package by mistake, we'd recommend publishing again under a different name, or for unpublished versions, bumping the version number and publishing again.\n\nYou might want to unpublish a package because you:\n\n* Published something accidentally.\n* Wanted to test npm.\n* Published content you [didn't intend to be public][oh-no].\n* Want to rename a package. (The only way to rename a package is to re-publish it under a new name)\n\n\n\n**Note:** `package-name@version` is unique, and cannot be reused by unpublishing and re-publishing it. We recommend publishing a minor version update instead.\n\n\n\n## When to deprecate\n\nIf you are no longer interested in maintaining a package, but want it to remain available for users to install, or if your package has dependents, we'd recommend [deprecating][deprecate-cli] it. To learn about how to deprecate a package, see \"[Deprecating and undeprecating packages or package versions][deprecate-package]\".\n\n\n[oh-no]: https://blog.npmjs.org/post/101934969510/oh-no-i-accidentally-published-private-data-to\n[deprecate-cli]: cli/deprecate\n[deprecate-package]: deprecating-and-undeprecating-packages-or-package-versions\n[two-factor-auth]: about-two-factor-authentication\n[unpublish]: /policies/unpublish\n[unpublish-cli]: /cli/unpublish\n"},{"id":"9b5f2016-386b-5b39-9579-da42ffe62e33","frontmatter":{"title":"Updating your published package version number"},"rawBody":"---\ntitle: Updating your published package version number\n---\n\nWhen you make significant changes to a published package, we recommend updating the version number to communicate the extent of the changes to others who rely on your code.\n\n\n\n**Note:** If you have linked a git repository to a package, updating the package version number will also add a tag with the updated release number to the linked git repository.\n\n\n\n1. To change the version number in `package.json`, on the command line, in the package root directory, run the following command, replacing `` with one of the [semantic versioning][semver] release types (patch, major, or minor):\n\n ```\n npm version \n ```\n\n2. Run `npm publish`.\n\n3. Go to your package page (`https://npmjs.com/package/`) to check that the package version has been updated.\n\nFor more information on `npm version`, see the [CLI documentation][cli-version].\n\n\n[semver]: about-semantic-versioning\n[cli-version]: /cli/version\n"},{"id":"87031dd6-68de-5593-aa55-54ed06e097c4","frontmatter":{"title":"CLI Commands"},"rawBody":"---\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/nav.yml\ntitle: CLI Commands\n---\n\n\n"},{"id":"d624a318-4150-5c8a-aaa2-69946b51e041","frontmatter":{"title":"npm-access"},"rawBody":"---\ntitle: npm-access\nsection: 1\ndescription: Set access level on published packages\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-access.md\n---\n\n### Synopsis\n\n```bash\nnpm access public []\nnpm access restricted []\n\nnpm access grant []\nnpm access revoke []\n\nnpm access 2fa-required []\nnpm access 2fa-not-required []\n\nnpm access ls-packages [||]\nnpm access ls-collaborators [ []]\nnpm access edit []\n```\n\n### Description\n\nUsed to set access controls on private packages.\n\nFor all of the subcommands, `npm access` will perform actions on the packages\nin the current working directory if no package name is passed to the\nsubcommand.\n\n* public / restricted:\n Set a package to be either publicly accessible or restricted.\n\n* grant / revoke:\n Add or remove the ability of users and teams to have read-only or read-write\n access to a package.\n\n* 2fa-required / 2fa-not-required:\n Configure whether a package requires that anyone publishing it have two-factor\n authentication enabled on their account.\n\n* ls-packages:\n Show all of the packages a user or a team is able to access, along with the\n access level, except for read-only public packages (it won't print the whole\n registry listing)\n\n* ls-collaborators:\n Show all of the access privileges for a package. Will only show permissions\n for packages to which you have at least read access. If `` is passed in,\n the list is filtered only to teams _that_ user happens to belong to.\n\n* edit:\n Set the access privileges for a package at once using `$EDITOR`.\n\n### Details\n\n`npm access` always operates directly on the current registry, configurable\nfrom the command line using `--registry=`.\n\nUnscoped packages are *always public*.\n\nScoped packages *default to restricted*, but you can either publish them as\npublic using `npm publish --access=public`, or set their access as public using\n`npm access public` after the initial publish.\n\nYou must have privileges to set the access of a package:\n\n* You are an owner of an unscoped or scoped package.\n* You are a member of the team that owns a scope.\n* You have been given read-write privileges for a package, either as a member\n of a team or directly as an owner.\n\nIf you have two-factor authentication enabled then you'll have to pass in an\notp with `--otp` when making access changes.\n\nIf your account is not paid, then attempts to publish scoped packages will fail\nwith an HTTP 402 status code (logically enough), unless you use\n`--access=public`.\n\nManagement of teams and team memberships is done with the `npm team` command.\n\n### See Also\n\n* [`libnpmaccess`](https://npm.im/libnpmaccess)\n* [npm team](/cli/v6/commands/npm-team)\n* [npm publish](/cli/v6/commands/npm-publish)\n* [npm config](/cli/v6/commands/npm-config)\n* [npm registry](/cli/v6/using-npm/registry)\n"},{"id":"56282ba5-718f-58fe-8c4e-7c079f7ddff2","frontmatter":{"title":"npm-adduser"},"rawBody":"---\ntitle: npm-adduser\nsection: 1\ndescription: Add a registry user account\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-adduser.md\n---\n\n### Synopsis\n\n```bash\nnpm adduser [--registry=url] [--scope=@orgname] [--always-auth] [--auth-type=legacy]\n\naliases: login, add-user\n```\n\n### Description\n\nCreate or verify a user named `` in the specified registry, and\nsave the credentials to the `.npmrc` file. If no registry is specified,\nthe default registry will be used (see [`config`](/cli/v6/using-npm/config)).\n\nThe username, password, and email are read in from prompts.\n\nTo reset your password, go to \n\nTo change your email address, go to \n\nYou may use this command multiple times with the same user account to\nauthorize on a new machine. When authenticating on a new machine,\nthe username, password and email address must all match with\nyour existing record.\n\n`npm login` is an alias to `adduser` and behaves exactly the same way.\n\n### Configuration\n\n#### registry\n\nDefault: https://registry.npmjs.org/\n\nThe base URL of the npm package registry. If `scope` is also specified,\nthis registry will only be used for packages with that scope. `scope` defaults\nto the scope of the project directory you're currently in, if any. See [`scope`](/cli/v6/using-npm/scope).\n\n#### scope\n\nDefault: none\n\nIf specified, the user and login credentials given will be associated\nwith the specified scope. See [`scope`](/cli/v6/using-npm/scope). You can use both at the same time,\ne.g.\n\n```bash\n npm adduser --registry=http://myregistry.example.com --scope=@myco\n``` \n\nThis will set a registry for the given scope and login or create a user for\nthat registry at the same time.\n\n#### always-auth\n\nDefault: false\n\nIf specified, save configuration indicating that all requests to the given\nregistry should include authorization information. Useful for private\nregistries. Can be used with `--registry` and / or `--scope`, e.g.\n\n```bash\n npm adduser --registry=http://private-registry.example.com --always-auth\n```\n\nThis will ensure that all requests to that registry (including for tarballs)\ninclude an authorization header. This setting may be necessary for use with\nprivate registries where metadata and package tarballs are stored on hosts with\ndifferent hostnames. See `always-auth` in [`config`](/cli/v6/using-npm/config) for more details on always-auth. Registry-specific configuration of `always-auth` takes precedence over any global configuration.\n\n#### auth-type\n\n* Default: `'legacy'`\n* Type: `'legacy'`, `'sso'`, `'saml'`, `'oauth'`\n\nWhat authentication strategy to use with `adduser`/`login`. Some npm registries\n(for example, npmE) might support alternative auth strategies besides classic\nusername/password entry in legacy npm.\n\n### See Also\n\n* [npm registry](/cli/v6/using-npm/registry)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n* [npm owner](/cli/v6/commands/npm-owner)\n* [npm whoami](/cli/v6/commands/npm-whoami)\n"},{"id":"ce51fb4a-50b8-5d03-8a87-920dbd121e84","frontmatter":{"title":"npm-audit"},"rawBody":"---\ntitle: npm-audit\nsection: 1\ndescription: Run a security audit\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-audit.md\n---\n\n### Synopsis\n\n```bash\nnpm audit [--json|--parseable|--audit-level=(low|moderate|high|critical)]\nnpm audit fix [--force|--package-lock-only|--dry-run]\n\ncommon options: [--production] [--only=(dev|prod)]\n```\n\n### Examples\n\nScan your project for vulnerabilities and automatically install any compatible\nupdates to vulnerable dependencies:\n```bash\n$ npm audit fix\n```\n\nRun `audit fix` without modifying `node_modules`, but still updating the\npkglock:\n```bash\n$ npm audit fix --package-lock-only\n```\n\nSkip updating `devDependencies`:\n```bash\n$ npm audit fix --only=prod\n```\n\nHave `audit fix` install semver-major updates to toplevel dependencies, not just\nsemver-compatible ones:\n```bash\n$ npm audit fix --force\n```\n\nDo a dry run to get an idea of what `audit fix` will do, and _also_ output\ninstall information in JSON format:\n```bash\n$ npm audit fix --dry-run --json\n```\n\nScan your project for vulnerabilities and just show the details, without fixing\nanything:\n```bash\n$ npm audit\n```\n\nGet the detailed audit report in JSON format:\n```bash\n$ npm audit --json\n```\n\nGet the detailed audit report in plain text result, separated by tab characters, allowing for\nfuture reuse in scripting or command line post processing, like for example, selecting\nsome of the columns printed:\n```bash\n$ npm audit --parseable\n```\n\nTo parse columns, you can use for example `awk`, and just print some of them:\n```bash\n$ npm audit --parseable | awk -F $'\\t' '{print $1,$4}'\n```\n\nFail an audit only if the results include a vulnerability with a level of moderate or higher:\n```bash\n$ npm audit --audit-level=moderate\n```\n\n### Description\n\nThe audit command submits a description of the dependencies configured in\nyour project to your default registry and asks for a report of known\nvulnerabilities. The report returned includes instructions on how to act on\nthis information. The command will exit with a 0 exit code if no\nvulnerabilities were found.\n\nYou can also have npm automatically fix the vulnerabilities by running `npm\naudit fix`. Note that some vulnerabilities cannot be fixed automatically and\nwill require manual intervention or review. Also note that since `npm audit fix`\nruns a full-fledged `npm install` under the hood, all configs that apply to the\ninstaller will also apply to `npm install` -- so things like `npm audit fix\n--package-lock-only` will work as expected.\n\nBy default, the audit command will exit with a non-zero code if any vulnerability\nis found. It may be useful in CI environments to include the `--audit-level` parameter\nto specify the minimum vulnerability level that will cause the command to fail. This\noption does not filter the report output, it simply changes the command's failure\nthreshold.\n\n### Content Submitted\n\n* npm_version\n* node_version\n* platform\n* node_env\n* A scrubbed version of your package-lock.json or npm-shrinkwrap.json\n\n#### Scrubbing\n\nIn order to ensure that potentially sensitive information is not included in\nthe audit data bundle, some dependencies may have their names (and sometimes\nversions) replaced with opaque non-reversible identifiers. It is done for\nthe following dependency types:\n\n* Any module referencing a scope that is configured for a non-default\n registry has its name scrubbed. (That is, a scope you did a `npm login --scope=@ourscope` for.)\n* All git dependencies have their names and specifiers scrubbed.\n* All remote tarball dependencies have their names and specifiers scrubbed.\n* All local directory and tarball dependencies have their names and specifiers scrubbed.\n\nThe non-reversible identifiers are a sha256 of a session-specific UUID and the\nvalue being replaced, ensuring a consistent value within the payload that is\ndifferent between runs.\n\n### Exit Code\n\nThe `npm audit` command will exit with a 0 exit code if no vulnerabilities were found.\n\nIf vulnerabilities were found the exit code will depend on the `audit-level`\nconfiguration setting.\n\n### See Also\n\n* [npm install](/cli/v6/commands/npm-install)\n* [package-locks](/cli/v6/configuring-npm/package-locks)\n* [config](/cli/v6/using-npm/config)\n"},{"id":"35860864-7510-556a-a070-acf9316b0cb9","frontmatter":{"title":"npm-bin"},"rawBody":"---\ntitle: npm-bin\nsection: 1\ndescription: Display npm bin folder\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-bin.md\n---\n\n### Synopsis\n```bash\nnpm bin [-g|--global]\n```\n\n### Description\n\nPrint the folder where npm will install executables.\n\n### See Also\n\n* [npm prefix](/cli/v6/commands/npm-prefix)\n* [npm root](/cli/v6/commands/npm-root)\n* [npm folders](/cli/v6/configuring-npm/folders)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n"},{"id":"86ad796b-f3f9-55ab-a183-fecd20583d05","frontmatter":{"title":"npm-bugs"},"rawBody":"---\ntitle: npm-bugs\nsection: 1\ndescription: Bugs for a package in a web browser maybe\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-bugs.md\n---\n\n### Synopsis\n```bash\nnpm bugs []\n\naliases: issues\n```\n\n### Description\n\nThis command tries to guess at the likely location of a package's\nbug tracker URL, and then tries to open it using the `--browser`\nconfig param. If no package name is provided, it will search for\na `package.json` in the current folder and use the `name` property.\n\n### Configuration\n\n#### browser\n\n* Default: OS X: `\"open\"`, Windows: `\"start\"`, Others: `\"xdg-open\"`\n* Type: String\n\nThe browser that is called by the `npm bugs` command to open websites.\n\n#### registry\n\n* Default: https://registry.npmjs.org/\n* Type: url\n\nThe base URL of the npm package registry.\n\n\n### See Also\n\n* [npm docs](/cli/v6/commands/npm-docs)\n* [npm view](/cli/v6/commands/npm-view)\n* [npm publish](/cli/v6/commands/npm-publish)\n* [npm registry](/cli/v6/using-npm/registry)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n* [package.json](/cli/v6/configuring-npm/package-json)\n"},{"id":"1b580263-503b-5bc5-bf2b-76aef1a83d85","frontmatter":{"title":"npm-build"},"rawBody":"---\ntitle: npm-build\nsection: 1\ndescription: Build a package\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-build.md\n---\n\n### Synopsis\n```shell\nnpm build []\n```\n\n* ``:\n A folder containing a `package.json` file in its root.\n\n### Description\n\nThis is the plumbing command called by `npm link` and `npm install`.\n\nIt should generally be called during installation, but if you need to run it\ndirectly, run:\n```bash\n npm build\n```\n\n### See Also\n\n* [npm install](/cli/v6/commands/npm-install)\n* [npm link](/cli/v6/commands/npm-link)\n* [npm scripts](/cli/v6/using-npm/scripts)\n* [package.json](/cli/v6/configuring-npm/package-json)\n"},{"id":"3f229705-f996-5169-8477-94818e3c2515","frontmatter":{"title":"npm-bundle"},"rawBody":"---\ntitle: npm-bundle\nsection: 1\ndescription: REMOVED\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-bundle.md\n---\n\n### Description\n\nThe `npm bundle` command has been removed in 1.0, for the simple reason\nthat it is no longer necessary, as the default behavior is now to\ninstall packages into the local space.\n\nJust use `npm install` now to do what `npm bundle` used to do.\n\n### See Also\n\n* [npm install](/cli/v6/commands/npm-install)\n"},{"id":"679734a4-84cd-5487-9280-1e027d8d83e0","frontmatter":{"title":"npm-cache"},"rawBody":"---\ntitle: npm-cache\nsection: 1\ndescription: Manipulates packages cache\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-cache.md\n---\n\n### Synopsis\n\n```bash\nnpm cache add \nnpm cache add \nnpm cache add \nnpm cache add @\n\nnpm cache clean []\naliases: npm cache clear, npm cache rm\n\nnpm cache verify\n```\n\n### Description\n\nUsed to add, list, or clean the npm cache folder.\n\n* add:\n Add the specified package to the local cache. This command is primarily\n intended to be used internally by npm, but it can provide a way to\n add data to the local installation cache explicitly.\n\n* clean:\n Delete all data out of the cache folder.\n\n* verify:\n Verify the contents of the cache folder, garbage collecting any unneeded data,\n and verifying the integrity of the cache index and all cached data.\n\n### Details\n\nnpm stores cache data in an opaque directory within the configured `cache`,\nnamed `_cacache`. This directory is a `cacache`-based content-addressable cache\nthat stores all http request data as well as other package-related data. This\ndirectory is primarily accessed through `pacote`, the library responsible for\nall package fetching as of npm@5.\n\nAll data that passes through the cache is fully verified for integrity on both\ninsertion and extraction. Cache corruption will either trigger an error, or\nsignal to `pacote` that the data must be refetched, which it will do\nautomatically. For this reason, it should never be necessary to clear the cache\nfor any reason other than reclaiming disk space, thus why `clean` now requires\n`--force` to run.\n\nThere is currently no method exposed through npm to inspect or directly manage\nthe contents of this cache. In order to access it, `cacache` must be used\ndirectly.\n\nnpm will not remove data by itself: the cache will grow as new packages are\ninstalled.\n\n### A note about the cache's design\n\nThe npm cache is strictly a cache: it should not be relied upon as a persistent\nand reliable data store for package data. npm makes no guarantee that a\npreviously-cached piece of data will be available later, and will automatically\ndelete corrupted contents. The primary guarantee that the cache makes is that,\nif it does return data, that data will be exactly the data that was inserted.\n\nTo run an offline verification of existing cache contents, use `npm cache\nverify`.\n\n### Configuration\n\n#### cache\n\nDefault: `~/.npm` on Posix, or `%AppData%/npm-cache` on Windows.\n\nThe root cache folder.\n\n### See Also\n\n* [npm folders](/cli/v6/configuring-npm/folders)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n* [npm install](/cli/v6/commands/npm-install)\n* [npm publish](/cli/v6/commands/npm-publish)\n* [npm pack](/cli/v6/commands/npm-pack)\n* https://npm.im/cacache\n* https://npm.im/pacote\n"},{"id":"ca93a0a3-f79b-5d9a-a468-01605ba7ea46","frontmatter":{"title":"npm-ci"},"rawBody":"---\ntitle: npm-ci\nsection: 1\ndescription: Install a project with a clean slate\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-ci.md\n---\n\n### Synopsis\n```bash\nnpm ci\n```\n\n### Example\n\nMake sure you have a package-lock and an up-to-date install:\n\n```bash\n$ cd ./my/npm/project\n$ npm install\nadded 154 packages in 10s\n$ ls | grep package-lock\n```\n\nRun `npm ci` in that project\n\n```bash\n$ npm ci\nadded 154 packages in 5s\n```\n\nConfigure Travis to build using `npm ci` instead of `npm install`:\n\n```bash\n# .travis.yml\ninstall:\n- npm ci\n# keep the npm cache around to speed up installs\ncache:\n directories:\n - \"$HOME/.npm\"\n```\n\n### Description\n\nThis command is similar to [`npm install`](/cli/v6/commands/npm-install), except it's meant to be used in\nautomated environments such as test platforms, continuous integration, and\ndeployment -- or any situation where you want to make sure you're doing a clean\ninstall of your dependencies. It can be significantly faster than a regular npm\ninstall by skipping certain user-oriented features. It is also more strict than\na regular install, which can help catch errors or inconsistencies caused by the\nincrementally-installed local environments of most npm users.\n\nIn short, the main differences between using `npm install` and `npm ci` are:\n\n* The project **must** have an existing `package-lock.json` or `npm-shrinkwrap.json`.\n* If dependencies in the package lock do not match those in `package.json`, `npm ci` will exit with an error, instead of updating the package lock.\n* `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.\n* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.\n* It will never write to `package.json` or any of the package-locks: installs are essentially frozen.\n\n### See Also\n\n* [npm install](/cli/v6/commands/npm-install)\n* [package-locks](/cli/v6/configuring-npm/package-locks)\n"},{"id":"84cd9146-af0d-58f8-a84a-5680ca3b515d","frontmatter":{"title":"npm-completion"},"rawBody":"---\ntitle: npm-completion\nsection: 1\ndescription: Tab Completion for npm\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-completion.md\n---\n\n### Synopsis\n```bash\nsource <(npm completion)\n```\n\n### Description\n\nEnables tab-completion in all npm commands.\n\nThe synopsis above\nloads the completions into your current shell. Adding it to\nyour ~/.bashrc or ~/.zshrc will make the completions available\neverywhere:\n\n```bash\nnpm completion >> ~/.bashrc\nnpm completion >> ~/.zshrc\n```\n\nYou may of course also pipe the output of `npm completion` to a file\nsuch as `/usr/local/etc/bash_completion.d/npm` or \n`/etc/bash_completion.d/npm` if you have a system that will read \nthat file for you.\n\nWhen `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the\nenvironment, `npm completion` acts in \"plumbing mode\", and outputs\ncompletions based on the arguments.\n\n### See Also\n\n* [npm developers](/cli/v6/using-npm/developers)\n* [npm](/cli/v6/commands/npm)\n"},{"id":"70ca1a7f-b780-512e-a4b1-8040b72d3f81","frontmatter":{"title":"npm-config"},"rawBody":"---\ntitle: npm-config\nsection: 1\ndescription: Manage the npm configuration files\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-config.md\n---\n\n### Synopsis\n```bash\nnpm config set [-g|--global]\nnpm config get \nnpm config delete \nnpm config list [-l] [--json]\nnpm config edit\nnpm get \nnpm set [-g|--global]\n\naliases: c\n```\n\n### Description\n\nnpm gets its config settings from the command line, environment\nvariables, `npmrc` files, and in some cases, the `package.json` file.\n\nSee [npmrc](/cli/v6/configuring-npm/npmrc) for more information about the npmrc files.\n\nSee [config](/cli/v6/using-npm/config) for a more thorough discussion of the mechanisms\ninvolved.\n\nThe `npm config` command can be used to update and edit the contents\nof the user and global npmrc files.\n\n### Sub-commands\n\nConfig supports the following sub-commands:\n\n#### set\n```bash\nnpm config set key value\n```\nSets the config key to the value.\n\nIf value is omitted, then it sets it to \"true\".\n\n#### get\n```bash\nnpm config get key\n```\n\nEcho the config value to stdout.\n\n#### list\n```bash\nnpm config list\n```\n\nShow all the config settings. Use `-l` to also show defaults. Use `--json`\nto show the settings in json format.\n\n#### delete\n```bash\nnpm config delete key\n```\n\nDeletes the key from all configuration files.\n\n#### edit\n```bash\nnpm config edit\n```\n\nOpens the config file in an editor. Use the `--global` flag to edit the\nglobal config.\n\n### See Also\n\n* [npm folders](/cli/v6/configuring-npm/folders)\n* [npm config](/cli/v6/commands/npm-config)\n* [package.json](/cli/v6/configuring-npm/package-json)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n* [npm](/cli/v6/commands/npm)\n"},{"id":"bfda055d-b160-52c2-9b5d-675ce3cdd0db","frontmatter":{"title":"npm-dedupe"},"rawBody":"---\ntitle: npm-dedupe\nsection: 1\ndescription: Reduce duplication\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-dedupe.md\n---\n\n### Synopsis\n```bash\nnpm dedupe\nnpm ddp\n\naliases: find-dupes, ddp\n```\n\n### Description\n\nSearches the local package tree and attempts to simplify the overall\nstructure by moving dependencies further up the tree, where they can\nbe more effectively shared by multiple dependent packages.\n\nFor example, consider this dependency graph:\n\n```bash\na\n+-- b <-- depends on c@1.0.x\n| `-- c@1.0.3\n`-- d <-- depends on c@~1.0.9\n `-- c@1.0.10\n```\n\nIn this case, `npm dedupe` will transform the tree to:\n\n```bash\na\n+-- b\n+-- d\n`-- c@1.0.10\n```\n\nBecause of the hierarchical nature of node's module lookup, b and d\nwill both get their dependency met by the single c package at the root\nlevel of the tree.\n\nThe deduplication algorithm walks the tree, moving each dependency as far\nup in the tree as possible, even if duplicates are not found. This will\nresult in both a flat and deduplicated tree.\n\nIf a suitable version exists at the target location in the tree\nalready, then it will be left untouched, but the other duplicates will\nbe deleted.\n\nArguments are ignored. Dedupe always acts on the entire tree.\n\nModules\n\nNote that this operation transforms the dependency tree, but will never\nresult in new modules being installed.\n\n### See Also\n\n* [npm ls](/cli/v6/commands/npm-ls)\n* [npm update](/cli/v6/commands/npm-update)\n* [npm install](/cli/v6/commands/npm-install)\n"},{"id":"9ea5feb3-b5a3-538e-9b9b-60d12f632e4b","frontmatter":{"title":"npm-deprecate"},"rawBody":"---\ntitle: npm-deprecate\nsection: 1\ndescription: Deprecate a version of a package\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-deprecate.md\n---\n\n### Synopsis\n```bash\nnpm deprecate [@] \n```\n\n### Description\n\nThis command will update the npm registry entry for a package, providing\na deprecation warning to all who attempt to install it.\n\nIt works on [version ranges](https://semver.npmjs.com/) as well as specific \nversions, so you can do something like this:\n```bash\nnpm deprecate my-thing@\"< 0.2.3\" \"critical bug fixed in v0.2.3\"\n```\n\nNote that you must be the package owner to deprecate something. See the\n`owner` and `adduser` help topics.\n\nTo un-deprecate a package, specify an empty string (`\"\"`) for the `message` \nargument. Note that you must use double quotes with no space between them to \nformat an empty string.\n\n### See Also\n\n* [npm publish](/cli/v6/commands/npm-publish)\n* [npm registry](/cli/v6/using-npm/registry)\n"},{"id":"288265f9-aebc-5ec1-bb41-cd8121edff9f","frontmatter":{"title":"npm-dist-tag"},"rawBody":"---\ntitle: npm-dist-tag\nsection: 1\ndescription: Modify package distribution tags\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-dist-tag.md\n---\n\n### Synopsis\n```bash\nnpm dist-tag add @ []\nnpm dist-tag rm \nnpm dist-tag ls []\n\naliases: dist-tags\n```\n\n### Description\n\nAdd, remove, and enumerate distribution tags on a package:\n\n* add:\n Tags the specified version of the package with the specified tag, or the\n `--tag` config if not specified. If you have two-factor authentication on\n auth-and-writes then you’ll need to include a one-time password on the\n command line with `--otp `.\n\n* rm:\n Clear a tag that is no longer in use from the package.\n\n* ls:\n Show all of the dist-tags for a package, defaulting to the package in\n the current prefix. This is the default action if none is specified.\n\nA tag can be used when installing packages as a reference to a version instead\nof using a specific version number:\n\n```bash\nnpm install @\n```\n\nWhen installing dependencies, a preferred tagged version may be specified:\n\n```bash\nnpm install --tag \n```\n\nThis also applies to `npm dedupe`.\n\nPublishing a package sets the `latest` tag to the published version unless the\n`--tag` option is used. For example, `npm publish --tag=beta`.\n\nBy default, `npm install ` (without any `@` or `@`\nspecifier) installs the `latest` tag.\n\n### Purpose\n\nTags can be used to provide an alias instead of version numbers.\n\nFor example, a project might choose to have multiple streams of development\nand use a different tag for each stream,\ne.g., `stable`, `beta`, `dev`, `canary`.\n\nBy default, the `latest` tag is used by npm to identify the current version of\na package, and `npm install ` (without any `@` or `@`\nspecifier) installs the `latest` tag. Typically, projects only use the `latest`\ntag for stable release versions, and use other tags for unstable versions such\nas prereleases.\n\nThe `next` tag is used by some projects to identify the upcoming version.\n\nBy default, other than `latest`, no tag has any special significance to npm\nitself.\n\n### Caveats\n\nThis command used to be known as `npm tag`, which only created new tags, and so\nhad a different syntax.\n\nTags must share a namespace with version numbers, because they are specified in\nthe same slot: `npm install @` vs `npm install @`.\n\nTags that can be interpreted as valid semver ranges will be rejected. For\nexample, `v1.4` cannot be used as a tag, because it is interpreted by semver as\n`>=1.4.0 <1.5.0`. See .\n\nThe simplest way to avoid semver problems with tags is to use tags that do not\nbegin with a number or the letter `v`.\n\n### See Also\n\n* [npm publish](/cli/v6/commands/npm-publish)\n* [npm install](/cli/v6/commands/npm-install)\n* [npm dedupe](/cli/v6/commands/npm-dedupe)\n* [npm registry](/cli/v6/using-npm/registry)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n"},{"id":"fe5d9c8f-e7c5-5811-9fd2-410e277affde","frontmatter":{"title":"npm-docs"},"rawBody":"---\ntitle: npm-docs\nsection: 1\ndescription: Docs for a package in a web browser maybe\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-docs.md\n---\n\n### Synopsis\n\n```bash\nnpm docs [ [ ...]]\nnpm docs .\nnpm home [ [ ...]]\nnpm home .\n```\n\n### Description\n\nThis command tries to guess at the likely location of a package's\ndocumentation URL, and then tries to open it using the `--browser`\nconfig param. You can pass multiple package names at once. If no\npackage name is provided, it will search for a `package.json` in\nthe current folder and use the `name` property.\n\n### Configuration\n\n#### browser\n\n* Default: OS X: `\"open\"`, Windows: `\"start\"`, Others: `\"xdg-open\"`\n* Type: String\n\nThe browser that is called by the `npm docs` command to open websites.\n\n#### registry\n\n* Default: https://registry.npmjs.org/\n* Type: url\n\nThe base URL of the npm package registry.\n\n\n### See Also\n\n* [npm view](/cli/v6/commands/npm-view)\n* [npm publish](/cli/v6/commands/npm-publish)\n* [npm registry](/cli/v6/using-npm/registry)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n* [package.json](/cli/v6/configuring-npm/package-json)\n"},{"id":"b3646d42-771c-5781-8be1-d53d236233a9","frontmatter":{"title":"npm-doctor"},"rawBody":"---\ntitle: npm-doctor\nsection: 1\ndescription: Check your environments\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-doctor.md\n---\n\n### Synopsis\n\n```bash\nnpm doctor\n```\n\n### Description\n\n`npm doctor` runs a set of checks to ensure that your npm installation has\nwhat it needs to manage your JavaScript packages. npm is mostly a standalone tool, but it does\nhave some basic requirements that must be met:\n\n+ Node.js and git must be executable by npm.\n+ The primary npm registry, `registry.npmjs.com`, or another service that uses\n the registry API, is available.\n+ The directories that npm uses, `node_modules` (both locally and globally),\n exist and can be written by the current user.\n+ The npm cache exists, and the package tarballs within it aren't corrupt.\n\nWithout all of these working properly, npm may not work properly. Many issues\nare often attributable to things that are outside npm's code base, so `npm\ndoctor` confirms that the npm installation is in a good state.\n\nAlso, in addition to this, there are also very many issue reports due to using\nold versions of npm. Since npm is constantly improving, running `npm@latest` is\nbetter than an old version.\n\n`npm doctor` verifies the following items in your environment, and if there are\nany recommended changes, it will display them.\n\n#### `npm ping`\n\nBy default, npm installs from the primary npm registry, `registry.npmjs.org`.\n`npm doctor` hits a special ping endpoint within the registry. This can also be\nchecked with `npm ping`. If this check fails, you may be using a proxy that\nneeds to be configured, or may need to talk to your IT staff to get access over\nHTTPS to `registry.npmjs.org`.\n\nThis check is done against whichever registry you've configured (you can see\nwhat that is by running `npm config get registry`), and if you're using a\nprivate registry that doesn't support the `/whoami` endpoint supported by the\nprimary registry, this check may fail.\n\n#### `npm -v`\n\nWhile Node.js may come bundled with a particular version of npm, it's the\npolicy of the CLI team that we recommend all users run `npm@latest` if they\ncan. As the CLI is maintained by a small team of contributors, there are only\nresources for a single line of development, so npm's own long-term support\nreleases typically only receive critical security and regression fixes. The\nteam believes that the latest tested version of npm is almost always likely to\nbe the most functional and defect-free version of npm.\n\n#### `node -v`\n\nFor most users, in most circumstances, the best version of Node will be the\nlatest long-term support (LTS) release. Those of you who want access to new\nECMAscript features or bleeding-edge changes to Node's standard library may be\nrunning a newer version, and some of you may be required to run an older\nversion of Node because of enterprise change control policies. That's OK! But\nin general, the npm team recommends that most users run Node.js LTS.\n\n#### `npm config get registry`\n\nSome of you may be installing from private package registries for your project\nor company. That's great! Others of you may be following tutorials or\nStackOverflow questions in an effort to troubleshoot problems you may be\nhaving. Sometimes, this may entail changing the registry you're pointing at.\nThis part of `npm doctor` just lets you, and maybe whoever's helping you with\nsupport, know that you're not using the default registry.\n\n#### `which git`\n\nWhile it's documented in the README, it may not be obvious that npm needs Git\ninstalled to do many of the things that it does. Also, in some cases\n– especially on Windows – you may have Git set up in such a way that it's not\naccessible via your `PATH` so that npm can find it. This check ensures that Git\nis available.\n\n#### Permissions checks\n\n* Your cache must be readable and writable by the user running npm.\n* Global package binaries must be writable by the user running npm.\n* Your local `node_modules` path, if you're running `npm doctor` with a project\n directory, must be readable and writable by the user running npm.\n\n#### Validate the checksums of cached packages\n\nWhen an npm package is published, the publishing process generates a checksum\nthat npm uses at install time to verify that the package didn't get corrupted\nin transit. `npm doctor` uses these checksums to validate the package tarballs\nin your local cache (you can see where that cache is located with `npm config\nget cache`, and see what's in that cache with `npm cache ls` – probably more\nthan you were expecting!). In the event that there are corrupt packages in your\ncache, you should probably run `npm cache clean` and reset the cache.\n\n### See Also\n\n* [npm bugs](/cli/v6/commands/npm-bugs)\n* [npm help](/cli/v6/commands/npm-help)\n* [npm ping](/cli/v6/commands/npm-ping)\n"},{"id":"af6fd056-420d-53f4-af8e-3e7fb91d1a54","frontmatter":{"title":"npm-edit"},"rawBody":"---\ntitle: npm-edit\nsection: 1\ndescription: Edit an installed package\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-edit.md\n---\n\n### Synopsis\n\n```bash\nnpm edit [/...]\n```\n\n### Description\n\nSelects a (sub)dependency in the current\nworking directory and opens the package folder in the default editor\n(or whatever you've configured as the npm `editor` config -- see\n[`npm-config`](npm-config).)\n\nAfter it has been edited, the package is rebuilt so as to pick up any\nchanges in compiled packages.\n\nFor instance, you can do `npm install connect` to install connect\ninto your package, and then `npm edit connect` to make a few\nchanges to your locally installed copy.\n\n### Configuration\n\n#### editor\n\n* Default: `EDITOR` environment variable if set, or `\"vi\"` on Posix,\n or `\"notepad\"` on Windows.\n* Type: path\n\nThe command to run for `npm edit` or `npm config edit`.\n\n### See Also\n\n* [npm folders](/cli/v6/configuring-npm/folders)\n* [npm explore](/cli/v6/commands/npm-explore)\n* [npm install](/cli/v6/commands/npm-install)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n"},{"id":"0ffc3b3a-0889-58a4-9dcf-ebdb4092ac09","frontmatter":{"title":"npm-explore"},"rawBody":"---\ntitle: npm-explore\nsection: 1\ndescription: Browse an installed package\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-explore.md\n---\n\n### Synopsis\n\n```bash\nnpm explore [ -- ]\n```\n\n### Description\n\nSpawn a subshell in the directory of the installed package specified.\n\nIf a command is specified, then it is run in the subshell, which then\nimmediately terminates.\n\nThis is particularly handy in the case of git submodules in the\n`node_modules` folder:\n\n```bash\nnpm explore some-dependency -- git pull origin master\n```\n\nNote that the package is *not* automatically rebuilt afterwards, so be\nsure to use `npm rebuild ` if you make any changes.\n\n### Configuration\n\n#### shell\n\n* Default: SHELL environment variable, or \"bash\" on Posix, or \"cmd\" on\n Windows\n* Type: path\n\nThe shell to run for the `npm explore` command.\n\n### See Also\n\n* [npm folders](/cli/v6/configuring-npm/folders)\n* [npm edit](/cli/v6/commands/npm-edit)\n* [npm rebuild](/cli/v6/commands/npm-rebuild)\n* [npm build](/cli/v6/commands/npm-build)\n* [npm install](/cli/v6/commands/npm-install)\n"},{"id":"5a1649c3-6819-5495-8548-7e6ec06e1024","frontmatter":{"title":"npm-fund"},"rawBody":"---\ntitle: npm-fund\nsection: 1\ndescription: Retrieve funding information\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-fund.md\n---\n\n### Synopsis\n\n```bash\n npm fund []\n```\n\n### Description\n\nThis command retrieves information on how to fund the dependencies of\na given project. If no package name is provided, it will list all\ndependencies that are looking for funding in a tree-structure in which\nare listed the type of funding and the url to visit. If a package name\nis provided then it tries to open its funding url using the `--browser`\nconfig param; if there are multiple funding sources for the package, the\nuser will be instructed to pass the `--which` command to disambiguate.\n\nThe list will avoid duplicated entries and will stack all packages\nthat share the same type/url as a single entry. Given this nature the\nlist is not going to have the same shape of the output from `npm ls`.\n\n### Configuration\n\n#### browser\n\n* Default: OS X: `\"open\"`, Windows: `\"start\"`, Others: `\"xdg-open\"`\n* Type: String\n\nThe browser that is called by the `npm fund` command to open websites.\n\n#### json\n\n* Type: Boolean\n* Default: false\n\nShow information in JSON format.\n\n#### unicode\n\n* Type: Boolean\n* Default: true\n\nWhether to represent the tree structure using unicode characters.\nSet it to `false` in order to use all-ansi output.\n\n#### which\n\n* Type: Number\n* Default: undefined\n\nIf there are multiple funding sources, which 1-indexed source URL to open.\n\n## See Also\n\n* [npm docs](/cli/v6/commands/npm-docs)\n* [npm config](/cli/v6/commands/npm-config)\n* [npm install](/cli/v6/commands/npm-install)\n* [npm ls](/cli/v6/commands/npm-ls)\n\n"},{"id":"d6d78c2a-5d49-5b55-86d1-c413aa42af84","frontmatter":{"title":"npm-help-search"},"rawBody":"---\ntitle: npm-help-search\nsection: 1\ndescription: Search npm help documentation\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-help-search.md\n---\n\n### Synopsis\n\n```bash\nnpm help-search \n```\n\n### Description\n\nThis command will search the npm markdown documentation files for the\nterms provided, and then list the results, sorted by relevance.\n\nIf only one result is found, then it will show that help topic.\n\nIf the argument to `npm help` is not a known help topic, then it will\ncall `help-search`. It is rarely if ever necessary to call this\ncommand directly.\n\n### Configuration\n\n#### long\n\n* Type: Boolean\n* Default: false\n\nIf true, the \"long\" flag will cause help-search to output context around\nwhere the terms were found in the documentation.\n\nIf false, then help-search will just list out the help topics found.\n\n### See Also\n\n* [npm](/cli/v6/commands/npm)\n* [npm help](/cli/v6/commands/npm-help)\n"},{"id":"1270eeff-8112-5ea4-8e99-789b5bca14d5","frontmatter":{"title":"npm-help"},"rawBody":"---\ntitle: npm-help\nsection: 1\ndescription: Get help on npm\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-help.md\n---\n\n### Synopsis\n\n```bash\nnpm help []\n```\n\n### Description\n\nIf supplied a topic, then show the appropriate documentation page.\n\nIf the topic does not exist, or if multiple terms are provided, then run\nthe `help-search` command to find a match. Note that, if `help-search`\nfinds a single subject, then it will run `help` on that topic, so unique\nmatches are equivalent to specifying a topic name.\n\n### Configuration\n\n#### viewer\n\n* Default: \"man\" on Posix, \"browser\" on Windows\n* Type: path\n\nThe program to use to view help content.\n\nSet to `\"browser\"` to view html help content in the default web browser.\n\n### See Also\n\n* [npm](/cli/v6/commands/npm)\n* [npm folders](/cli/v6/configuring-npm/folders)\n* [npm config](/cli/v6/commands/npm-config)\n* [npmrc](/cli/v6/configuring-npm/npmrc)\n* [package.json](/cli/v6/configuring-npm/package-json)\n* [npm help-search](/cli/v6/commands/npm-help-search)\n"},{"id":"06052cc6-757b-5f1f-8c99-ceace6591a1c","frontmatter":{"title":"npm-hook"},"rawBody":"---\ntitle: npm-hook\nsection: 1\ndescription: Manage registry hooks\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-hook.md\n---\n\n### Synopsis\n\n```bash\nnpm hook ls [pkg]\nnpm hook add \nnpm hook update [secret]\nnpm hook rm \n```\n\n### Example\n\nAdd a hook to watch a package for changes:\n```bash\n$ npm hook add lodash https://example.com/ my-shared-secret\n```\n\nAdd a hook to watch packages belonging to the user `substack`:\n```bash\n$ npm hook add ~substack https://example.com/ my-shared-secret\n```\n\nAdd a hook to watch packages in the scope `@npm`\n```bash\n$ npm hook add @npm https://example.com/ my-shared-secret\n```\n\nList all your active hooks:\n```bash\n$ npm hook ls\n```\n\nList your active hooks for the `lodash` package:\n```bash\n$ npm hook ls lodash\n```\n\nUpdate an existing hook's url:\n```bash\n$ npm hook update id-deadbeef https://my-new-website.here/\n```\n\nRemove a hook:\n```bash\n$ npm hook rm id-deadbeef\n```\n\n### Description\n\nAllows you to manage [npm hooks](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm),\nincluding adding, removing, listing, and updating.\n\nHooks allow you to configure URL endpoints that will be notified whenever a\nchange happens to any of the supported entity types. Three different types of\nentities can be watched by hooks: packages, owners, and scopes.\n\nTo create a package hook, simply reference the package name.\n\nTo create an owner hook, prefix the owner name with `~` (as in, `~youruser`).\n\nTo create a scope hook, prefix the scope name with `@` (as in, `@yourscope`).\n\nThe hook `id` used by `update` and `rm` are the IDs listed in `npm hook ls` for\nthat particular hook.\n\nThe shared secret will be sent along to the URL endpoint so you can verify the\nrequest came from your own configured hook.\n\n### See Also\n\n* [\"Introducing Hooks\" blog post](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm)\n"},{"id":"5cfa054f-6585-5be3-8a46-1263832cdbb9","frontmatter":{"title":"npm-init"},"rawBody":"---\ntitle: npm-init\nsection: 1\ndescription: create a package.json file\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-init.md\n---\n\n### Synopsis\n```bash\nnpm init [--force|-f|--yes|-y|--scope]\nnpm init <@scope> (same as `npx <@scope>/create`)\nnpm init [<@scope>/] (same as `npx [<@scope>/]create-`)\n```\n\n### Examples\n\nCreate a new React-based project using [`create-react-app`](https://npm.im/create-react-app):\n```bash\n$ npm init react-app ./my-react-app\n```\n\nCreate a new `esm`-compatible package using [`create-esm`](https://npm.im/create-esm):\n```bash\n$ mkdir my-esm-lib && cd my-esm-lib\n$ npm init esm --yes\n```\n\nGenerate a plain old package.json using legacy init:\n```bash\n$ mkdir my-npm-pkg && cd my-npm-pkg\n$ git init\n$ npm init\n```\n\nGenerate it without having it ask any questions:\n```bash\n$ npm init -y\n```\n\n### Description\n\n`npm init ` can be used to set up a new or existing npm package.\n\n`initializer` in this case is an npm package named `create-`, which\nwill be installed by [`npx`](https://npm.im/npx), and then have its main bin\nexecuted -- presumably creating or updating `package.json` and running any other\ninitialization-related operations.\n\nThe init command is transformed to a corresponding `npx` operation as follows:\n\n* `npm init foo` -> `npx create-foo`\n* `npm init @usr/foo` -> `npx @usr/create-foo`\n* `npm init @usr` -> `npx @usr/create`\n\nAny additional options will be passed directly to the command, so `npm init foo\n--hello` will map to `npx create-foo --hello`.\n\nIf the initializer is omitted (by just calling `npm init`), init will fall back\nto legacy init behavior. It will ask you a bunch of questions, and then write a\npackage.json for you. It will attempt to make reasonable guesses based on\nexisting fields, dependencies, and options selected. It is strictly additive, so\nit will keep any fields and values that were already set. You can also use\n`-y`/`--yes` to skip the questionnaire altogether. If you pass `--scope`, it\nwill create a scoped package.\n\n### See Also\n\n* \n* [package.json](/cli/v6/configuring-npm/package-json)\n* [npm version](/cli/v6/commands/npm-version)\n* [npm scope](/cli/v6/using-npm/scope)\n"},{"id":"bf34eb7d-55a3-53d7-a9f8-54e074fd85db","frontmatter":{"title":"npm-install-ci-test"},"rawBody":"---\ntitle: npm-install-ci-test\nsection: 1\ndescription: Install a project with a clean slate and run tests\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-install-ci-test.md\n---\n\n### Synopsis\n\n```bash\nnpm install-ci-test\n\nalias: npm cit\n```\n\n### Description\n\nThis command runs an `npm ci` followed immediately by an `npm test`.\n\n### See Also\n\n* [npm ci](/cli/v6/commands/npm-ci)\n* [npm test](/cli/v6/commands/npm-test)\n"},{"id":"8216c32a-ac02-5fa8-b76c-9afe9950119e","frontmatter":{"title":"npm-install-test"},"rawBody":"---\ntitle: npm-install-test\nsection: 1\ndescription: Install package(s) and run tests\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-install-test.md\n---\n\n### Synopsis\n\n```bash\nnpm install-test (with no args, in package dir)\nnpm install-test [<@scope>/]\nnpm install-test [<@scope>/]@\nnpm install-test [<@scope>/]@\nnpm install-test [<@scope>/]@\nnpm install-test \nnpm install-test \nnpm install-test \n\nalias: npm it\ncommon options: [--save|--save-dev|--save-optional] [--save-exact] [--dry-run]\n```\n\n### Description\n\nThis command runs an `npm install` followed immediately by an `npm test`. It\ntakes exactly the same arguments as `npm install`.\n\n### See Also\n\n* [npm install](/cli/v6/commands/npm-install)\n* [npm test](/cli/v6/commands/npm-test)\n"},{"id":"a378dccc-31e1-5f0e-9857-b4cf1261f588","frontmatter":{"title":"npm-install"},"rawBody":"---\ntitle: npm-install\nsection: 1\ndescription: Install a package\ngithub_repo: npm/cli\ngithub_branch: v6\ngithub_path: docs/content/commands/npm-install.md\n---\n\n### Synopsis\n\n```bash\nnpm install (with no args, in package dir)\nnpm install [<@scope>/]\nnpm install [<@scope>/]@\nnpm install [<@scope>/]@\nnpm install [<@scope>/]@\nnpm install @npm:\nnpm install :/\nnpm install \nnpm install \nnpm install \nnpm install \n\naliases: npm i, npm add\ncommon options: [-P|--save-prod|-D|--save-dev|-O|--save-optional] [-E|--save-exact] [-B|--save-bundle] [--no-save] [--dry-run]\n```\n\n### Description\n\nThis command installs a package, and any packages that it depends on. If the\npackage has a package-lock or shrinkwrap file, the installation of dependencies\nwill be driven by that, with an `npm-shrinkwrap.json` taking precedence if both\nfiles exist. See [package-lock.json](/cli/v6/configuring-npm/package-lock-json) and [`npm shrinkwrap`](/cli/v6/commands/npm-shrinkwrap).\n\nA `package` is:\n\n* a) a folder containing a program described by a [`package.json`](/cli/v6/configuring-npm/package-json) file\n* b) a gzipped tarball containing (a)\n* c) a url that resolves to (b)\n* d) a `@