request 库升级造成大量低版本 node.js 平台报错

[mdluo]

直播地址： https://github.com/request/request/issues/2891

背景介绍：

大概两个多小时前（ 2018 年 3 月 12 日下午 4 点左右） request 库发布了 v2.84.1 版本，更新包括合并了这个 PR，主要是把依赖的 hawk 这个做加密的库从 6.0.2 升级到了 7.0.7。而 hawk 的这次大版本升级引入了一个叫 sntp 的库。这个库里这么一句话造成了大量错误反馈：

exports.time = async function (options = {}) {

自己搭的 node.js 服务器受影响可能性比较小，毕竟 v6 算是很古老的版本了。但是一些云平台，比如 AWS Lambda 支持的 node.js 版本是 v6.10 ，Google Cloud Functions 支持的版本是 v6.11.5，参考 node.green，很明显都是不支持 async 的。

我在这个 issue 下回复之后现在正在不断的收到提示邮件...

[pmispig]

又一次依赖惨案

[mdluo]

作者及时发布了更新 v2.85.0 把 hawk 升级的 PR 给 revert 了，惨案暂告段落

总结经验教训： https://git.io/vxv2g

[kslr]

锁死版本不怕不怕

[chenqh]

哎。。

[duan602728596]

233333333

[inflationaaron]

依赖地狱是 Node.js 的特色，不得不品尝

[janxin]

锁版本了解一下？ semver 兼容性约定了解一下？依赖地狱了解一下？ XD

[Mcatt]

为啥不锁版本

[raphaelsoul]

为什么不锁版本？？？

[mdluo]

@janxin #7
@Mcatt #8
@raphaelsoul #9

请不要站在上帝视角让用户去锁版本，因为用户没法预料哪个包会出问题。而且锁版本是 package-lock.json 或者 yarn.lock 的事情，自己手动去 package.json 里锁版本只能当成紧急措施，因为既锁不住深层依赖，也不方便后序升级更新。第三方依赖包小版本升级造成严重问题的情况相比修复潜在问题的情况还是少很多的。

request 这次的主要问题因为这个 PR （ https://github.com/request/request/pull/2880 ）明明没有通过 CI 但还是被作者给无脑 merge 了。应该吸取的经验教训是单元测试一定要写，CI 一定要用而且结果也很重要。不管是开源项目还是商业项目，尤其是有很多人参与的项目。另外如果写的一个库的用户很多，也要注意在 node.js v6 版本的兼容性，因为很多云平台还是在这个版本。

[Mcatt]

@mdluo

我同意你说的开源项目一定要跑 CI

不过对于线上稳定运行的项目不是一般不轻易升级依赖吗？