浅谈 npm 依赖治理
2022年6月28日 12:16
想想项目创建之后，多久没给 npm 依赖升级了？
如何得知当前项目 npm 依赖的“健康度”？
给老项目升级 npm 依赖，有哪些注意事项？
核心诉求
- 提高可维护性。不容易和后引入的依赖产生冲突。引入新特性，功能表现和文档描述接近，后续开发也能得心应手。
- 提高可移植性。方便老项目向高版本 npm 或 pnpm 迁移。
- 提高可靠性。只要依赖还在稳定迭代，升级必定能引入一系列 bugfix（却也可能引入新 bug）。
- 提高安全性。官方社区会及时通告 npm 依赖的安全漏洞，将版本保持在安全范围，能排除许多隐患。
流程方法
- 使用专业的评估工具。手动升级 @latest 等于把依赖当成黑盒来操作。
- 按优先级处理。集中精力升级核心依赖，以及含有安全隐患的库，否则时间投入很容易超出预期。
- 阅读 changelog，评估升级影响。
- 回归测试，十分重要。
除了回归测试以外，主导治理的人不仅要熟悉项目内容，也要对计划升级的 npm 包有充分了解。如果没有合适的人选，建议继续在代码堆里坚持一会儿，毕竟升级有风险，后果得自负。
检索工具
以下内容以 npm 为例，pnpm 和 yarn 有可替代的命令。
过时依赖 npm outdated
npm outdated 命令会从 npm 源检查已安装的软件包是否已过时。
随便拿几个包举例：
1 | Package Current Wanted Latest Location |
默认只会检查项目 package.json 中直接引用的依赖， --all 选项可以用来匹配全部的依赖。但没有必要，真要彻底升级，更推荐尝试重建 lock 文件。
对于 outdated 的包，使用 npm update 或其他包管理工具对应的 update 命令即可安装 SemVer 标准执行升级。如果想跨越 Major 版本，则需要手动指定升级版本。
风险依赖 npm audit
npm audit 命令同样是向 npm 源发起请求，它将 package-lock.json 作为参数，返回存在已知漏洞的依赖列表。 换句话说，audit 不需要安装 node_modules 就可以执行，其结果完全取决于当前的 package-lock.json。
返回节选如下：