写在前面
npm 有很多命令，有很多并不常用，而有些则非常常用，还有些很有用，但很多人却不知道，下面列出了一些常见和一些非常有用的命令，并详细说明了它的用法。
ls (alias list, la, ll)
使用该命令可以列出当前项目依赖的模块，比较常见的参数有 depth
只列出最上层的依赖
npm ls --depth=0
使用 npm la 可以一并列出模块的简要说明（也就是存在于 description 中的内容）。
link
这是一个相当有用的命名，对于开发这很重要。设想一下场景：
你在开发一个模块 A，同时需要在另外一个项目 B 中测试它，你当然可以将该模块的代码移动到需要使用它的项目中，但这也不是理想的方法。
此时可以使用 link 来解决。npm link 的使用分为两步。
第一步
在模块 A 的项目根目录下执行 npm link，这个时候 npm 会将模块 A 通过链接安装在全局。
第二步
在项目 B 的根目录下执行 npm link A，此后就可以在项目 B 中使用 require(‘A’) 来使用 A 模块了。因为只是链接，所以 A 模块的任何修改，都会事实地同步过来。
install (alias i)
这个命令想必都很熟悉了，用来安装模块。只是安装模块的来源有很多种，有来自 git 地址的，有来自 npm 的，有来自 github 仓库的，如何来安装这些来自不同途径的模块呢？
npm install
不带任何参数，这会安装 package.json 中记录的模块。
npm install
从 npm 源上安装一个模块
npm install @<version|tag>
从 npm 源上安装指定版本或者 tag 的模块
npm install
从一个 git 地址上安装模块，比如：
npm install git+ssh://[email protected]:npm/npm.git#v1.0.27
npm install git+https://[email protected]/npm/npm.git
npm install git://github.com/npm/npm.git#v1.0.27
npm install /[#]
从 github 上的每个开发这的仓库里安装，比如安装最新的 express：
默认会安装 master 分支
npm i expressjs/express
安装 5.0 分支
npm i expressjs/express#5.0
npm install file:
从本地文件系统安装，比如：
npm i file:…/moduleA
安装上层目录的 moduleA
安装来源真非常多，更多方式请参考 npm install。
uninstall
移除一个模块，这会移除某个模块自身和其依赖，为了将其从 package.json 中也删除，需要添加 --save 或者 --save-dev 选项。
shrinkwrap
npm 推荐开发者使用 semver 来设置模块的版本号，而且 npm 默认使用 ^1.0.0 这种形式来记录版本（关于这 ^ 代表什么，请参照前面的文章），初衷是让开发者能够时刻使用确保功能正常且又是最新的代码。但不能保证开发者遵守了这个规定。且即使在 dependencies 中明确写定某个模块的版本，也不能保证该模块依赖的模块的版本在下次升级的时候不会改变。
模块的不确定性导致开发阶段表现良好的代码，在部署以后出现了问题。为此需要做的是限定在下次安装的时候也只使用特定的版本。有的团队采用将 node_modules 也纳入版本管理的方案，只是这种方案存在太多缺点，代码库过大，某些在安装时候需要根据不同平台进行编译的模块无法正常工作，等等。
npm shrinkwrap 可以记录下当前项目使用的所有的模块的版本，并将他们记录在一个 npm-shrinkwrap.json 的文件中，在下次安装的时候 npm 会使用这里面记录的模板的版本来安装，这保证了下次安装的时候会使用和上次完全一致的版本。
如何使用 npm shrinkwrap
运行 npm install 安装所有模块
测试你的代码，保证没有问题
运行 npm shrinkwrap，并将产物 npm-shrinkwrap.json 纳入版本管理。
当你增加或者移除了依赖，这个时候需要重新生成一下 npm-shrinkwrap.json。之前的文章提到过，安装模块的顺序不同，会导致 node_modules 的结构不同，因此在增加或者移除了依赖后，可以删掉 node_modules 重新执行一次 npm i。
使用了 shrinkwrap 之后，用户在安装你的模块的时候也会安装符合你的模块要求的依赖，这样可以有效地避免因为依赖升级导致自己的项目挂掉。当然了，及时这样也不能保证，完全不会出问题，如果一个模块的维护者，强制更新了代码但是没有更改版本号，这还是可能会出现问题，所以在使用第三方模块的时候要小心选择。
run
我想这个命令的使用频率仅次于 install 了。在 npm 的基本用法 一文中提到了 npm script，npm run 就是用来运行这些指令的。
比如在 package.json 中有这样的内容：
{
“scripts”:{
“build”: “webpack”
}
}
为了运行 build 命令，需要执行 npm run build，在使用 npm run 的时候会将 node_modules/.bin 加入环境变量 PATH 中，在命令执行完了再移除，因此你不需要写成：
“build”: “./node_modules/.bin/webpack”
如果需要在命令行中给 webpack 传入一些参数，比如想要执行 webpack -p，这时候执行 npm run build -p 不会得到想要的结果，因为这里的 -p 应该传给 npm 还是传给你的脚本，很难说，你需要执行 npm run build – -p， npm 会将 – 后面的内容全部传给你的脚本。
运行 npm run 不带任何参数，会列出当前所有可用的 npm script。
关于 npm script 的内容后面还会细说。
adduser (alias login)
在发布模块的时候常常要先进行登录，这个时候就需要用到该命令，键入 npm adduser 后会要求输入用户名，密码，邮箱，默认是登录到 npm 上，如要登录到其他源上，需要使用 registry 选项，要想登录到某个 scope 中需要使用 scope 选项：
npm adduser --registry=http://myregistry.example.com --scope=@myco
whoami
就像 *nux 系统里面的 whoami 一样，npm whoami 会打印出当前登录的用户名，你可能登录过多个仓库，比如 npm 的，公司的 npm 等，此时需要指定 --registry 选项来看自己在某个 npm 源上登录的用户。
npm whoami --registry https://registry.npm.taobao.org
npm 有很多有用的命令，知道了这些常用的命令的使用方法，以及适用场景能够极大地加快效率，毕竟是每天都要使用的工具，有必要了解它、熟悉它。下一篇文章，准备谈谈 npm script 的相关知识。