vlambda博客
学习文章列表

is-promise 库主要用来测试 JavaScript 对象是否为“Promise”，并在开发时使用该函数返回布尔值 yes 或 no，开发者可以通过 one-liner 调用并在自己的项目中使用这个库。4 月 25 日，is-promise 正常进行更新，发布了 is-promise v2.2.0，但由于该版本并未遵循正确的 ES 模块标准，从而导致更新完成后，由于不正确的 ES 模块标准，所有在构建时使用 is-promise 库的项目几乎全部发生故障。虽然这一错误不会使现有项目崩溃，但它却对开发者编译自己项目的新版本造成了影响。

来看一下“肇事者”：

declare function isPromise<T, S>(obj: Promise<T> | S): obj is Promise<T>;export default isPromise;

虽然这个问题立即就被发现了，但仍影响到了一些 JavaScript 生态系统中的“大项目”，其中包括 Facebook 的 Create App，三大框架之一的 Angular，Google 的 Firebase 工具，亚马逊的 AWS Serverless CLI，Nuxt.js，AVA 等等。很多开发者都表示受到了影响：

https://github.com/then/is-promise/issues/13

GitHub 上显示，与该库有依赖关系的项目超过 340 万个。

两行代码险些搞垮 JavaScript 生态，受影响项目超百万

该团队在第一时间发布了 is-promise v2.2.1 更新，但是并未能解决问题，最终在几个小时后发布的 is-promise v2.2.2 中修正了 ES 模块支持的问题，这一“紧急事件”才落下帷幕。

仅仅两行代码就造成了这么大的影响，实际上这并不是第一次发生。早在 2016 年 3 月，一个名为 left-pad 且仅有 17 行代码的 npm 库也曾引发过一起事故，起因是这个库的作者创建了一个 npm 模块并命名为 kik，这个名字与当时的一个聊天软件 Kik 如出一辙，所以 Kik 的负责人找到该作者并希望他换一个名字，结果双方并没有谈妥，该作者一气之下突然决定取消发布所有的库，导致无数项目出现事故。

与 2016 年一样，“is-promise 事件”引发了一众开发者的疑问：是否需要在 JavaScript 生态中提供 one-liner 库？JavaScript 模块化究竟是否必需？

一部分开发者认为，当开发人员创建这种只有几行代码的库时，模块化实在是过于繁琐；而另一部分开发者则认为，模块化十分有必要，某一个任务可以在其对应的模块内统一管理，而不是让开发者以不同的方式在自己的项目中处理。

对于一个复杂的 Web 应用来说，模块化编程显然是一个更具优势的选择，很多 JavaScript 库都是这样实现的。在 ES6 之前，很多前端社区曾自己钻研模块化开发，经历了 AMD/CMD/UMD 等阶段，这里不过多赘述。ES6 中首次引入模块化开发规范，让 Javascript 首次支持原生模块化开发，从此，JavaScript 模块化被越来越多的开发者接受。

JavaScript 模块化也说明了 Web 的能力在不断增强，Web 应用日趋复杂。相信未来 JavaScript 的能力会继续提升，前端开发者们的开发效率也会更加高效。

参考阅读：

https://www.zdnet.com/article/another-one-line-npm-package-breaks-the-javascript-ecosystem/