blog4 min read
Package.json 依赖管理

这篇笔记包含 MDX 无法直接解析的旧 Markdown 语法。
原文内容仍然保留在文件中，可以逐步清理为标准 MDX。
# Package.json 依赖管理

我们使用 npm 安装包的时候，常常会安装很多依赖，等到项目上线后，项目代码一般不会改动了。可依赖包却也在不断地更新。那么我们依赖包是否需要同样不断更新？

## 是否需要升级依赖包

我们从开发者和用户两个角度思考一下。

### 用户角度

用户其实并不关心项目中的依赖，只要程序能够正常运行就好了，如果升级后导致了更多的问题，还会引起用户的反感。

### 开发者角度

开发者和用户不一样，由于前端更新换代非常快，库的更新也特别快，保持依赖库的更新，可以起到优化项目，利于维护等好处。

**优化项目**：新版本的库一般是对旧版本库的一些扩展、一些已知 bug 的修复、性能优化等。例如：同样使用 node 跑一次测试用例，node10 版本比 node6 版本构建时间要缩短 50% 以上。

**利于维护**：新版本的库都是最新的文档，查阅比较方便，如果遇到项目交接给一个新手，可以避免去学习一些老版本的语法，降低交接难度。

## 如何升级依赖包

1、最简单的方法是使用 npm update package_xxx 来升级一个包，但会受到包版本规则的影响。

package.json 中包版本号规则：

- ~1.0.0 匹配 1.0.x
- ^1.0.0 匹配 1.x.x
- 1.0.0 匹配 1.0.0
- \>1.0.0 匹配大于 1.0.0
- <1.0.0 匹配小于 1.0.0
- \* 匹配任何版本
- latest 匹配最新版本

2、使用 npm-check-updates，自动将所有 package.json 中的包更新为最新版。

```sh
# 全局安装
npm i npm-check-updates -g
# 在项目根目录执行命令
ncu -u
```

3、使用 [greenkeeper](https://greenkeeper.io/)。这个工具使用 github 账号登录后，选定指定项目，它会解析你的 package.json 文件，当有更新的依赖包被加载进来的时候，就会提交一个 Pull requests，这会触发 ci 构建，如果 ci 没什么问题，直接合并就好了。

如果 ci 有问题，证明新的依赖包可能更改了语法，或者不向下兼容了，**我们可以第一时间发现问题并处理**，而不必等到依赖包更新太多导致语法差异越来越大，到时候再想兼容新版本可就要费一番心思了。

4、如果你的依赖都是最新的，还可以在 [David](https://david-dm.org/)上添加小图标哦！

## 总结

关于是不是应该保持项目依赖的问题，我个人建议是：

- 使用自动化工具自动更新，
  - 单元测试通过，合并到项目中。
  - 单元测试不通过，及时查看报错信息，判断修改难度。
    - 难度小，例如：官方弃用了旧的 api，同时提供了新的 api 来代替，则需要及时进行更新。
    - 难度大，例如：官方重构了项目，api 结构、使用方式都发生了改变，则可以不进行更新。

## 参考地址

[HOW TO KEEP HIS NPM DEPENDENCIES UP-TO-DATE ?](http://blog.js-republic.com/keep-npm-dependencies-up-to-date/)

[版本号规范](https://semver.org/lang/zh-CN/)