**npm command** [[官方网站]](https://docs.npmjs.com/cli-documentation/) ~~~ npm <command> where <command> is one of: access, adduser, audit, bin, bugs, c, cache, ci, cit,clean-install, clean-install-test, completion, config, create, ddp, dedupe, deprecate, dist-tag, docs, doctor, edit, explore, get, help, help-search, hook, i, init, install, install-ci-test, install-test, it, link, list, ln, login, logout, ls, org, outdated, owner, pack, ping, prefix, profile, prune, publish, rb, rebuild, repo, restart, root, run, run-script, s, se, search, set, shrinkwrap, star, stars, start, stop, t, team, test, token, tst, un, uninstall, unpublish, unstar, up, update, v, version, view, whoami npm <command> -h quick help on <command> npm -l display full usage info npm help <term> search for help on <term> npm help npm involved overview ~~~ ***** 内容索引 [TOC] ***** ## `search` Search for packages **SYNOPSIS** ~~~ npm search [-l|--long] [--json] [--parseable] [--no-description] [search terms ...] aliases: s, se, find ~~~ **DESCRIPTION** Search the registry for packages matching the search terms.`npm search`performs a linear, incremental, lexically-ordered search through package metadata for all files in the registry. If color is enabled, it will further highlight the matches in the results. Additionally, using the`--searchopts`and`--searchexclude`options paired with more search terms will respectively include and exclude further patterns. The main difference between`--searchopts`and the standard search terms is that the former does not highlight results in the output and can be used for more fine-grained filtering. Additionally, both of these can be added to`.npmrc`for default search filtering behavior. Search also allows targeting of maintainers in search results, by prefixing their npm username with`=`. If a term starts with`/`, then it’s interpreted as a regular expression and supports standard JavaScript RegExp syntax. A trailing`/`will be ignored in this case. (Note that many regular expression characters must be escaped or quoted in most shells.) ## `init` create a package.json file **SYNOPSIS** ~~~ npm init [--force|-f|--yes|-y|--scope] npm init <@scope> (same as `npx <@scope>/create`) npm init [<@scope>/]<name> (same as `npx [<@scope>/]create-<name>`) ~~~ **EXAMPLES** Create a new React-based project using[`create-react-app`](https://npm.im/create-react-app): ~~~ $ npm init react-app ./my-react-app ~~~ Create a new`esm`\-compatible package using[`create-esm`](https://npm.im/create-esm): ~~~ $ mkdir my-esm-lib && cd my-esm-lib $ npm init esm --yes ~~~ Generate a plain old package.json using legacy init: ~~~ $ mkdir my-npm-pkg && cd my-npm-pkg $ git init $ npm init ~~~ Generate it without having it ask any questions: ~~~ $ npm init -y ~~~ **DESCRIPTION** `npm init <initializer>`can be used to set up a new or existing npm package. `initializer`in this case is an npm package named`create-<initializer>`, which will be installed by[](https://npm.im/npx)`[npx](https://docs.npmjs.com/cli/npx)`, and then have its main bin executed – presumably creating or updating`package.json`and running any other initialization-related operations. The init command is transformed to a corresponding`npx`operation as follows: * `npm init foo`\->`npx create-foo` * `npm init @usr/foo`\->`npx @usr/create-foo` * `npm init @usr`\->`npx @usr/create` Any additional options will be passed directly to the command, so`npm init foo --hello`will map to`npx create-foo --hello`. If the initializer is omitted (by just calling`npm init`), init will fall back to legacy init behavior. It will ask you a bunch of questions, and then write a package.json for you. It will attempt to make reasonable guesses based on existing fields, dependencies, and options selected. It is strictly additive, so it will keep any fields and values that were already set. You can also use`-y`/`--yes`to skip the questionnaire altogether. If you pass`--scope`, it will create a scoped package. ## `install` **SYNOPSIS** ~~~ npm install (with no args, in package dir) npm install [<@scope>/]<name> npm install [<@scope>/]<name>@<tag> npm install [<@scope>/]<name>@<version> npm install [<@scope>/]<name>@<version range> npm install <git-host>:<git-user>/<repo-name> npm install <git repo url> npm install <tarball file> npm install <tarball url> npm install <folder> aliases: npm i, npm add common options: [-P|--save-prod|-D|--save-dev|-O|--save-optional] [-E|--save-exact] [-B|--save-bundle] [--no-save] [--dry-run] ~~~ `npm install` saves any specified packages into `dependencies` by default. Additionally, you can control where and how they get saved with some additional flags: * `-P, --save-prod`: Package will appear in your`dependencies`. This is the default unless`-D`or`-O`are present. * `-D, --save-dev`: Package will appear in your`devDependencies`. When installing a package that will be bundled into your production bundle, you should use `--save`. If you're installing a package for development purposes (e.g. a linter, testing libraries, etc.) then you should use `--save-dev`. * `-O, --save-optional`: Package will appear in your`optionalDependencies`. * `--no-save`: Prevents saving to`dependencies`. When using any of the above options to save dependencies to your package.json, there are two additional, optional flags: * `-E, --save-exact`: Saved dependencies will be configured with an exact version rather than using npm’s default semver range operator. * `-B, --save-bundle`: Saved dependencies will also be added to your`bundleDependencies`list. **ALGORITHM** To install a package, npm uses the following algorithm: ~~~ load the existing node_modules tree from disk clone the tree fetch the package.json and assorted metadata and add it to the clone walk the clone and add any missing dependencies dependencies will be added as close to the top as is possible without breaking any other modules compare the original tree with the cloned tree and make a list of actions to take to convert one to the other execute all of the actions, deepest first kinds of actions are install, update, remove and move ~~~ For this`package{dep}`structure:`A{B,C}, B{C}, C{D}`, this algorithm produces: ~~~ A +-- B +-- C +-- D ~~~ That is, the dependency from B to C is satisfied by the fact that A already caused C to be installed at a higher level. D is still installed at the top level because nothing conflicts with it. For`A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces: ~~~ A +-- B +-- C `-- D@2 +-- D@1 ~~~ Because B’sD@1will be installed in the top level, C now has to installD@2privately for itself. This algorithm is deterministic, but different trees may be produced if two dependencies are requested for installation in a different order. See [npm-folders](https://docs.npmjs.com/files/folders) for a more detailed description of the specific folder structures that npm creates. ### 全局安装 ~~~ npm install -g ~~~ 1. 将安装包放在`/usr/local` 下 2. 可以直接在命令行里使用 ### 本地安装 ~~~ npm install ~~~ 1. 将安装包放在`./node_modules` 下（运行npm时所在的目录） 2. 可以通过 require() 来引入本地安装的包 ## `run` **SYNOPSIS** ~~~ npm run-script <command> [--silent] [-- <args>...] alias: npm run ~~~ **DESCRIPTION** This runs an arbitrary command from a package’s`"scripts"`object. If no`"command"`is provided, it will list the available scripts.`run[-script]`is used by the test, start, restart, and stop commands, but can be called directly, as well. When the scripts in the package are printed out, they’re separated into lifecycle (test, start, restart) and directly-run scripts. The`env`script is a special built-in command that can be used to list environment variables that will be available to the script at runtime. If an “env” command is defined in your package, it will take precedence over the built-in. In addition to the shell’s pre-existing`PATH`,`npm run`adds`node_modules/.bin`to the`PATH`provided to scripts. Any binaries provided by locally-installed dependencies can be used without the`node_modules/.bin`prefix. For example, if there is a`devDependency`on`tap`in your package, you should write: ~~~ "scripts": {"test": "tap test/\*.js"} ~~~ instead of ~~~ "scripts": {"test": "node_modules/.bin/tap test/\*.js"} ~~~ to run your tests. The actual shell your script is run within is platform dependent. By default, on Unix-like systems it is the`/bin/sh`command, on Windows it is the`cmd.exe`. The actual shell referred to by`/bin/sh`also depends on the system. Scripts are run from the root of the module, regardless of what your current working directory is when you call`npm run`. If you want your script to use different behavior based on what subdirectory you’re in, you can use the`INIT_CWD`environment variable, which holds the full path you were in when you ran`npm run`. `npm run`sets the`NODE`environment variable to the`node`executable with which`npm`is executed. If you try to run a script without having a`node_modules`directory and it fails, you will be given a warning to run`npm install`, just in case you’ve forgotten. You can use the`--silent`flag to prevent showing`npm ERR!`output on error. You can use the`--if-present`flag to avoid exiting with a non-zero exit code when the script is undefined. This lets you run potentially undefined scripts without breaking the execution chain. ## `uninstall` **SYNOPSIS** ~~~ npm uninstall [<@scope>/]<pkg>[@<version>]... [-S|--save|-D|--save-dev|-O|--save-optional|--no-save] aliases: remove, rm, r, un, unlink ~~~ **DESCRIPTION** This uninstalls a package, completely removing everything npm installed on its behalf. Example: ~~~ npm uninstall sax ~~~ >[info] In global mode (ie, with `-g` or `--global` appended to the command), it uninstalls the current package context as a global package. `npm uninstall` takes 3 exclusive, optional flags which save or update the package version in your main `package.json`: * `-S, --save`: Package will be removed from your `dependencies`. * `-D, --save-dev`: Package will be removed from your `devDependencies`. * `-O, --save-optional`: Package will be removed from your `optionalDependencies`. * `--no-save`: Package will not be removed from your `package.json` file. ## `view` View registry info **SYNOPSIS** ~~~ npm view [<@scope>/]<name>[@<version>] [<field>[.<subfield>]...] aliases: info, show, v ~~~ **DESCRIPTION** This command shows data about a package and prints it to the stream referenced by the `outfd` config, which defaults to stdout. **example** To show the package registry entry for the`connect`package: ~~~ npm view connect ~~~ To show the dependencies of the`ronn`package at version 0.3.5: ~~~ npm view ronn@0.3.5 dependencies ~~~ To view the git repository URL for the latest version of npm: ~~~ npm view npm repository.url ~~~ To view all the data about the version of opts that ronn depends on: ~~~ npm view opts@$(npm view ronn dependencies.opts) ~~~ To get all the contributors for the “express” project(For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list.): ~~~ npm view express contributors npm view express contributors.name npm view express contributors.email ~~~ To show the `jquery` package version history, you can do this: ~~~ npm view jquery versions ~~~ ## `config` Manage the npm configuration files **SYNOPSIS** ~~~ npm config set <key> <value> [-g|--global] npm config get <key> npm config delete <key> npm config list [-l] [--json] npm config edit npm get <key> npm set <key> <value> [-g|--global] aliases: c ~~~ **DESCRIPTION** npm gets its config settings from the command line, environment variables,`npmrc`files, and in some cases, the`package.json`file. See[npmrc](https://docs.npmjs.com/files/npmrc)for more information about the npmrc files. See `[npm-config](https://docs.npmjs.com/misc/config)` for a more thorough discussion of the mechanisms involved. The `npm config` command can be used to update and edit the contents of the user and global npmrc files. ## `root` Display npm root **SYNOPSIS** ~~~ npm root [-g] ~~~ **DESCRIPTION** Print the effective `node_modules` folder to standard out. ## `version` Bump a package version **SYNOPSIS** ~~~ npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git] 'npm [-v | --version]' to print npm version 'npm view <pkg> version' to view a package's published version 'npm ls' to inspect current package/dependency versions ~~~ **DESCRIPTION** Run this in a package directory to bump the version and write the new data back to `package.json`, `package-lock.json`, and, if present, `npm-shrinkwrap.json`. The `newversion` argument should be a valid semver string, a valid second argument to [semver.inc](https://github.com/npm/node-semver#functions)(one of`patch`,`minor`,`major`,`prepatch`,`preminor`,`premajor`,`prerelease`), or `from-git`. In the second case, the existing version will be incremented by 1 in the specified field. `from-git` will try to read the latest git tag, and use that as the new npm version. If run in a git repo, it will also create a version commit and tag. This behavior is controlled by`git-tag-version`(see below), and can be disabled on the command line by running`npm --no-git-tag-version version`. It will fail if the working directory is not clean, unless the`-f`or`--force`flag is set. If supplied with`-m`or`--message`config option, npm will use it as a commit message when creating a version commit. If the`message`config contains`%s`then that will be replaced with the resulting version number. For example: ~~~ npm version patch -m "Upgrade to %s for reasons" ~~~ If the`sign-git-tag`config is set, then the tag will be signed using the`-s`flag to git. Note that you must have a default GPG key set up in your git config for this to work properly. For example: ~~~ $ npm config set sign-git-tag true $ npm version patch You need a passphrase to unlock the secret key for user: "isaacs (http://blog.izs.me/) <i@izs.me>" 2048-bit RSA key, ID 6C481CF6, created 2010-08-31 Enter passphrase: ~~~ If`preversion`,`version`, or`postversion`are in the`scripts`property of the package.json, they will be executed as part of running`npm version`. The exact order of execution is as follows: 1. Check to make sure the git working directory is clean before we get started. Your scripts may add files to the commit in future steps. This step is skipped if the`--force`flag is set. 2. Run the`preversion`script. These scripts have access to the old`version`in package.json. A typical use would be running your full test suite before deploying. Any files you want added to the commit should be explicitly added using`git add`. 3. Bump`version`in`package.json`as requested (`patch`,`minor`,`major`, etc). 4. Run the`version`script. These scripts have access to the new`version`in package.json (so they can incorporate it into file headers in generated files for example). Again, scripts should explicitly add generated files to the commit using`git add`. 5. Commit and tag. 6. Run the`postversion`script. Use it to clean up the file system or automatically push the commit and/or tag. Take the following example: ~~~ "scripts": { "preversion": "npm test", "version": "npm run build && git add -A dist", "postversion": "git push && git push --tags && rm -rf build/temp" } ~~~ This runs all your tests, and proceeds only if they pass. Then runs your`build`script, and adds everything in the`dist`directory to the commit. After the commit, it pushes the new commit and tag up to the server, and deletes the`build/temp`directory. ## `upgrade` Update a package **SYNOPSIS** ~~~ npm update [-g] [<pkg>...] aliases: up, upgrade ~~~ **DESCRIPTION** This command will update all the packages listed to the latest version (specified by the`tag`config), respecting semver. It will also install missing packages. As with all commands that install packages, the`--dev`flag will cause`devDependencies`to be processed as well. If the`-g`flag is specified, this command will update globally installed packages. >[info] If no package name is specified, all packages in the specified location (global or local) will be updated. As of `npm@2.6.1`, the`npm update`will only inspect top-level packages. Prior versions of`npm`would also recursively inspect all dependencies. To get the old behavior, use`npm --depth 9999 update`. As of `npm@5.0.0`, the`npm update`will change`package.json`to save the new version as the minimum required dependency. To get the old behavior, use`npm update --no-save`. **EXAMPLE** hese examples assume`npm@2.6.1`or later. For older versions of`npm`, you must specify`--depth 0`to get the behavior described below. For the examples below, assume that the current package is`app`and it depends on dependencies,`dep1`(`dep2`, .. etc.). The published versions of`dep1`are: ~~~ { "dist-tags": { "latest": "1.2.2" }, "versions": [ "1.2.2", "1.2.1", "1.2.0", "1.1.2", "1.1.1", "1.0.0", "0.4.1", "0.4.0", "0.2.0" ] } ~~~ 1. Caret Dependencies If `app`’s `package.json` contains: ~~~ "dependencies": { "dep1": "^1.1.1" } ~~~ Then `npm update` will install `dep1@1.2.2`, because `1.2.2` is `latest` and `1.2.2` satisfies `^1.1.1`. 2. Tilde Dependencies However, if `app`’s `package.json` contains: ~~~ "dependencies": { "dep1": "~1.1.1" } ~~~ In this case, running`npm update`will install`dep1@1.1.2`. Even though the`latest`tag points to`1.2.2`, this version does not satisfy`~1.1.1`, which is equivalent to`>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies`~1.1.1`is used, which is`1.1.2`. 3. Caret Dependencies below 1.0.0 Suppose`app`has a caret dependency on a version below`1.0.0`, for example: ~~~ "dependencies": { "dep1": "^0.2.0" } ~~~ `npm update`will install`dep1@0.2.0`, because there are no other versions which satisfy`^0.2.0`. If the dependence were on`^0.4.0`: ~~~ "dependencies": { "dep1": "^0.4.0" } ~~~ Then`npm update`will install`dep1@0.4.1`, because that is the highest-sorting version that satisfies`^0.4.0`(`>= 0.4.0 <0.5.0`) `npm update -g`will apply the`update`action to each globally installed package that is`outdated`– that is, has a version that is different from`latest`. >[warning] NOTE: If a package has been upgraded to a version newer than`latest`, it will be *downgraded*. ## `link`?? Symlink a package folder **SYNOPSIS** ~~~ npm link (in package dir) npm link [<@scope>/]<pkg>[@<version>] alias: npm ln ~~~ ## `ls` List installed packages **SYNOPSIS** ~~~ npm ls [[<@scope>/]<pkg> ...] aliases: list, la, ll ~~~ **DESCRIPTION** This command will print to stdout all the versions of packages that are installed, as well as their dependencies, in a tree-structure. For example, running `npm ls promzard` in npm’s source tree will show: ~~~bash npm@@VERSION@ /path/to/npm └─┬ init-package-json@0.0.4 └── promzard@0.1.5 ~~~ It will print out extraneous, missing, and invalid packages. If a project specifies git urls for dependencies these are shown in parentheses after thename@versionto make it easier for users to recognize potential forks of a project. The tree shown is the logical dependency tree, based on package dependencies, not the physical layout of your node\_modules folder. When run as`ll`or`la`, it shows extended information by default. ### 查看全局安装过哪些包(插件) ~~~bash $ npm list -g --dept 0 ~~~ ### 查看全局安装的插件信息 ~~~bash $ npm ls 插件名字 -g ~~~ ### 查看本地安装的插件信息 ~~~bash $ npm ls 插件名字 ~~~