Node.js之npm 包管理工具

一、NPM创建项目

1. 使用npm创建项目

​ 在一个空文件夹下，通过终端执行下面的命令，完成后会生成一个package.json的配置文件。

# 项目初始化
npm init

# 使用默认设置初始化项目
npm init -y

2. npm init详解

name 项目名称
version 项目版本号
description 项目描述信息
entry point 项目入口文件
test command 项目启动的脚本命令
git repository 如果你有 Git 地址，可以将这个项目放到你的 Git 仓库里
keywords 关键词
author 作者
license 项目要发行的时候需要的证书，平时往往忽略

3. package.json详解

"private": true, // 是否私有，为true，npm会拒绝发布
"dependencies": { //生产依赖（项目发布后仍需要用到的模块，例如jQuery）
    "antd": "^2.11.1",
    "classnames": "^2.2.5"
},
"devDependencies": { //开发依赖（开发时使用的模块，不需要发布到线上）
    "axios": "^0.15.3",
    "babel-eslint": "^6.1.2"
},
"bin": { //命令行工具
    "dk-cli": "./bin/dk-cli.js"
},
"scripts": { //脚本命令（例如npm start 会自动在命令行中输入 node index.js）
    "start": "node index.js"
},
"engines": { //项目所依赖模块的版本信息
    "node": ">=6.9.0",
    "npm": ">=3.10.10"
}
"publishConfig": { //将包发布到NPM仓库（可以使用自定义地址）
    "registry": "http://gongsineibu/nexus/repository/npm-hosted/"
}

二、分清全局安装与本地安装

1. 全局安装和本地安装都安装到了哪？

⏰ 官方文档：使用 -g 安装的模块为全局安装，否则为本地安装。

使用 -g 安装全局模块

npm install express -g

不使用 -g 安装本地模块

npm install path

那么问题来了，全局模块和本地模块都安装到哪了？

⏰ 全局模块安装路径

// 输入指令查询全局模块安装路径
npm list -g --depth=0

⏰ 本地模块安装路径

本地模块安装在当前目录下的 node_modules 目录下。

假如安装本地模块的当前目录是 D:\code，那么在该目录下会自动创建 node_modules 目录（如果之前有这个目录就不会创建了），在 node_modules 目录下就可以找到刚才安装的 path 模块了。

2. 全局安装和本地安装的包有啥区别？

官方的解释是： 

🍀全局安装：全局安装的包直接安装到计算机中，只需安装一次，以后在计算机的任何位置都可以使用这个包；
☘️本地安装： 本地安装包安装到哪儿可以知道本地包是安装在当前目录下的，也就是说，只有在当前目录下才可以使用安装的本地包。比如上面安装的本地包 path，只有在 D:\code 目录下才能使用这个包，换做其它任何目录是不能使用它。

🔊 总结：全局安装安装一次重复使用，本地安装使用什么安装什么。

3. 哪些包我应该全局安装，哪些包又应该本地安装？

👉 约定俗成的，对于那些提供命令行工具的包进行全局安装，其它包本地安装。🤏

举例说明：

⏰ 安装 dva-cli 包

npm install dva-cli -g

使用命令行工具输入指令 dva new 创建 dva 脚手架

dva new dva-demo

⏰ 安装 eslint 包

npm install eslint -g

使用指令 --init 设置一个配置文件

eslint --init

所以像这种能提供指令的包通常进行全局安装

🔊 总结：不用管上面两个案例的指令具体是什么，只要提供指令的包都建议使用全局安装；其它包打包是提供一个功能，用于解决某一需求，建议安装成本地包。

三、安装模块

1. 安装全局模块

🔊 -g 参数代表着全局，英文单词 global，使用 -g 参数安装的是全局模块。-g 可以写在要安装的包前面或后面位置。

npm install express -g
或者 
npm install -g express

❓ 全局模块安装到了哪里？

// 输入指令查询全局模块安装路径
$ npm list -g --depth=0

2. 安装本地模块

🔊 不使用 -g 参数安装的模块都会安装到本地模块。

npm install path

❓ 本地模块安装到了哪里？

本地模块安装在当前目录下的 node_modules 目录下。

比如安装本地模块的当前目录是 D:\code，那么在该目录下会自动创建 node_modules 目录（如果之前有这个目录就不会创建了），在 node_modules 目录下就可以找到刚才安装的 path 模块了。

3. 安装指定版本的模块

🔊 前提是要知道具体的版本号，如果不知道，可以使用 @3.* 表示安装第三版中最新的包。

npm install react-router@3.*

4. 同时安装多个模块

🔊 有时候需要安装多个模块，一个个安装太过麻烦，可以一起安装，模块之间以空格隔开即可。

如下为同时安装 antd 模块和 babel-plugin-import 模块。

npm install antd babel-plugin-import

5. 安装 package.json 中的包

package.json 文件其中一个重要功能就是记录当前项目的依赖包有哪些。

比如我们在下载完一个项目时，通常只有安装完依赖包，才可以启动项目把项目给跑起来。这是我们可以通过查看 package.json 可以知道项目依赖哪些包，然后使用 npm install 指令可以安装 package.json 中记录的依赖包。

npm install   // 就是这么简单，当然前提是有 package.json 并且里面配置了相关包信息

6. --save 的用途

🔊 使用 --save 可以将模块信息记录到 package.json 文件中 dependencies 属性中。

--save 和 -g 一样，属于参数。 

在安装模块时，只有当事人知道安装了哪些模块，如果换另外一个人来看这个项目，是不会知道这个项目安装了哪些模块。

使用 --save 可以在安装模块时，同时将安装的模块信息记录在 package.json 文件中，这样第三个人再看这个项目时，就可以直接看 package.json 文件来了解这个项目依赖了哪些包。

npm install antd --save

7. --save-dev 的用途

🔊 与 --save 参数类似，--save-dev 也会将模块信息记录到 package.json 文件中，不同的是记录在文件中的 devDependencies 属性下。

npm install antd --save-dev

❓ dependencies 与 devDependencies 属性区别？

dependencies 指定了项目生产环境时所依赖的模块；
devDependencies 制定了项目开发环境时所依赖的模块。

四、卸载模块

1. 只卸载模块

🔊 由于之前安装过，在 package.json 中的记录仍然存在

npm uninstall lodash

2. --save 参数使用

🔊 卸载模块的同时删除在 package.json 文件中的记录

npm uninstall lodash --save

3. 卸载指定版本的模块

npm uninstall lodash@3.*  // 卸载 lodash 模块 3.* 版本

五、更新模块

1. 不带参数的更新模块

🔊 会更新到小版本号最新的那个版本，但不会更新到大版本号。

npm update lodash

2. --save 参数

🔊 更新模块的同时将更新信息记录到 package.json 文件中

npm update lodash --save

3. 指定更新的版本

🔊 就算指定版本，也只能更新到小版本号最新的那个版本，对大版本号不起作用

比如 lodash 的版本号有：3.9.1、3.10.1、4.13.1

当前已经安装的 lodash 版本是 3.9.1

npm update lodash@4.13.1 --save

此时由于对大版本号进行更新，结果没有任何响应，依然是 3.9.1 版本。

npm update lodash@3.10.* --save

此时并没有更改大版本号，更新结果为 lodash 的版本变成了 3.10.1 版本。

4. 更新模块注意事项

🔊 更新模块只能更新到小版本号最新的那个版本，不能更新大版本号。

一个模块的版本号由三部分组成：大版本号.小版本号.次版本号。如 lodash 模块的某个版本 3.9.1，其中：“3” 是大版本号， “9” 是小版本号， “1” 是次版本号。
使用 $ npm update lodash 只能将 3.9.1 更新到小版本号最大的那个版本，这里是 3.10.1，而不能更新到 4. 版本。这一点要*特别特别特别的注意。

六、查看模块

在实际项目中，我们可能需要查询全局/本地都安装了哪些模块，来做下一步的操作。本节介绍如何查询已经安装的模块。

1. 查看全局模块

与安装模块一样，-g 参数在 npm 中就代表着全局的含义。

npm list -g

使用这条指令不仅会打印出全局安装的模块，还会显示全局安装的路径。

你会发现，确实打印出来了所有的全局模块，但是这些模块的依赖模块也一并打印出来，结果就是一个很长很长的树级显示，不方便查找，后面介绍解决方法。

2. 查看本地模块

不使用 -g 参数查询的就是已安装的本地模块，但前提是当前目录下有 node_modules 目录。

npm list

使用这条指令也会打印出本地模块安装路径。

⚠️ 良好的操作习惯是在安装模块时使用 --save 将安装了哪些模块都记录在 package.json 中，这样如果要查询可以直接去 package.json 中查看即可。

3. --depth=0 参数的用法

🔊 --depth=0 表示查询模块，只显示第一层级的模块。这里的 0 如果换成 1 就是显示第一层级和第二层级的模块，依次类推。

⏰ 查看全局模块的一级目录

npm list -g --depth=0

⏰ 查询本地模块的两级目录

npm list --depth=1

七、其它一些问题

1. npm 发布包的版本指定规则

使用 Npm 发布一个包的时候，往往要遵循 x.y.z 的规则，发布的第一个版本一般为 1.0.0。

• z 补丁号：修改某个功能的 Bug 时，z 值 +1 变成 1.0.1；
• y 小版本号：增加一个新功能，且不影响已有功能，y 值 +1 变成 1.1.0；
• x 大版本号：引入新的变化，破坏向后兼容，x 值 +1 变成 2.0.0。

2. 关于向后兼容与向前兼容

向前兼容和向后兼容可以用下面这个例子方便理解。

• 向后兼容：Windows 10要能运行为Windows 3.1开发的程序；
• 破坏向后兼容：新版本的系统不能运行老版本系统上的程序，可以理解为整容的跟以前完全不一样了；
• 向前兼容：Windows 3.1要能运行为Windows 10开发的程序。

3. package.json 中包版本 ~ 与 ^ 说明

🔊 package.json 中会记录很多包的版本号，前面大多出现 ^ 和 ~ 符号，表示某个包的版本号取值范围，包的版本号在这个范围之内都是可以的。

 "devDependencies": {
    "axios": "^0.15.3",
    "babel-eslint": "^6.1.2",
    "babel-plugin-dva-hmr": "^0.3.2",
    "babel-plugin-import": "^1.1.1",
    "draftjs-to-html": "^0.7.0",
    "eslint": "^3.17.1",
    "eslint-config-airbnb": "^9.0.1",
    "eslint-plugin-import": "^1.16.0",
    "eslint-plugin-jsx-a11y": "^1.4.2",
    "eslint-plugin-react": "^5.1.1",
    "less-vars-to-js": "^1.1.2",
    "path-to-regexp": "^1.7.0",
    "rc-tween-one": "^1.0.0",
    "redbox-react": "^1.2.10",
    "roadhog": "0.6.0-beta.6"
  },

假定某个包的版本是 1.4.0

⏰ ~1.4.0

表示：>=1.4.0 && < 1.5.0

说明：小版本不变，补丁号可以取最大值。

^1.4.0

表示：>=1.4.0 && < 2.0.0

说明：大版本号不变，小版本号可以取最大值。