几步简单的操作解决 `npm audit` vulnerabilities

NPM 是 JavaScript 生态最重要的组成部分，我们的项目中会大量使用 NPM 安装第三方包（安装后就称为“项目依赖”）解决问题。这些第三方包也会带来他们的依赖，最终一个项目里可能安装成百上千个依赖。

有道是：没有完美的代码，代码里一定藏有隐患。所以用的依赖多了，其中有问题的概率也提升了，三五不时的，npm 就会提示我们：found N low/medium/high severity vulnerabilities。

npm 提供命令 npm audit fix，理论上可以修复这些隐患，但在实际操作中，以我的经验来看，并不容易生效。我猜测可能是因为依赖间的复杂关系，想彻底解决并升级不太容易。所以我一般是这样做的：

1. GitHub 或者 NPM 告诉我有 “(potential security) vulnerabilities”
2. 因为我的项目以前端为主，所以基本上问题不大，所以我会等两天，等仓库主人修复仓库
3. 大约 1～2 周后，打开项目，先试一下 npm audit fix
4. 能修好当然最好，不能修好就只好升级：npm update
5. 升级完可能还会有 vulnerabilities，没关系，因为前面说过，依赖间的关系很复杂，npm 可能没有办法很好的解决。所以这个时候，删掉 node_modules 和 package-lock.json，然后重新安装依赖 npm i
6. 大部分情况下，这个时候就 OK 了。有时候还不行，那就 npm outdated 看一眼有没有可以升级的大版本
7. JavaScript 生态里，因为 ES 版本的关系、TS 的关系，大版本升级往往没有非常剧烈的 API 变动，很多时候，比如从 3.0 => 4.0，也可以平滑升级（webpack 除外）。默认情况下，安装后的依赖都用 ^a.b.c 指定版本，即不低于 a.b.c，且大版本不能超过 a。所以 npm update 的时候，不会升级大版本。但是我们可以研究一下，比如看一下 release note，然后升级大版本：npm i some-repo@4（仍以 3 => 4 为例）
8. 提醒一下，虽然以我的经验，大版本升级 80% 是安全的，但也有不小的可能导致项目出问题，如果你的项目没有很好的测试覆盖，或者你没有很好的测试用例积累，那么不要轻易升级。建议单独立项稳妥升级。
9. 大部分情况下应该问题解决，如果还不行，重复（5）
10. 如果大版本升级也解决不了，那么可以再等等。
11. 如果是 node.js 项目，最好尽快解决，不要等，可以直接手动升级隐患依赖的版本好。

总结

这套方案的好处在于简单，基本敲几个命令等一会儿就行，依赖本身就应该经常升级，但应该有测试覆盖。