一个单行代码 npm 包使得 JavaScript 生态系统陷入混乱
上周六,一个很小的 JavaScript 库的更新使得大部分 JavaScript 生态系统陷入了混乱。据 ZDNet 指出,大约有数百万个项目在这一事件中受到了影响。
而令人感到震惊地是,引起整个混乱的仅仅是一个“单行代码(one-liner) ” 的 JavaScript 库。这也是第二次发生由小型 JavaScript 项目引起广泛问题的情况。第一次是发生在 2016 年 3 月,当时 left-pad JavaScript 库的作者(一个总共只有 17 行代码的项目)突然决定取消发布该库,以类似的方式破坏了数千个项目。
而上周末导致一系列问题的这个软件包名为 is-promise,该库由两行原始源代码组成,开发人员可以通过单行调用在自己的项目中使用它。其目的是让开发人员测试 JavaScript 对象是否为“Promise”函数:用于生产环境中时,该函数返回 yes 或 no 的布尔值。
然而,尽管只是两行执行基本检查的代码,is-promise 库仍是当今最受欢迎的 JavaScript npm 软件包(库)之一。根据 GitHub 的说法,该库是超过 340 万个项目的一部分,并被 766 个其他 JavaScript 库用作依赖项。
上周末,is-promise 库进行了更新,以获取作为 ES 模块(JavaScript 语言使用的标准化模块系统)的支持。但是,is-promise v.2.2.0 版本却未遵循正确的 ES 模块标准。因此更新发布后,由于其不正确的 ES 模块支持 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] ,在各自的构建链(build chain)中使用 is-promise 的众多项目纷纷开始出现问题。
该错误迅速地引发了一连串的影响,范围涵盖至封闭源 JavaScript 代码库和 JavaScript 生态系统中一些最大的项目。其中包括有:Facebook 的 Create React App(用于创建 React 应用程序的标准模板)、谷歌的 Angular.js 框架、谷歌的 Firebasse-tools、亚马逊的 AWS Serverless CLI、Nuxt.js 和 AVA 等。
So this just happened.
Is-Promise just made a little change and it broke multiple packages.
So far as I've read its broken Firebase-tools, angular cli, aws serveless cli, create react app, possibly more.https://t.co/3ZZofevWNR— Preet™ (@TmPreet) April 25, 2020
该 bug 并没有导致现有项目崩溃,因此没有出现实际的停运故障,但其确实害得广大开发人员无法编译各自项目的新版本。
之后,is-promise 团队发布了一个更新,但并未能解决该问题,最终还是在 v2.2.2 版本中撤回了支持 ES 模块的功能。
与 2016 年的情况一样,is-promise 事件引发了人们的疑问,大家开始讨论 JavaScript 生态系统中是不是真的需要单行代码库。就像 2016 年以及多年前其他编程语言的生态系统所提出的那样,同样的观点再次被提了出来。
有人认为,如果开发人员创建的库只有短短几行代码,对于最无关紧要的操作而言,模块化做得过头了,毫无必要。还有人认为,需要对这些项目进行模块化,因为以这种方式,“任务 A”可以在一个模块中进行管理,而不是让成千上万的开发人员在自己的项目中以不同的方式来处理它。
事实上,有关模块化的讨论已经存在了多年,因此在短期时间内可能也得不出什么结论。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
GNOME Shell 日历修复过度消耗 CPU 并影响电池寿命的 Bug
五个月前,GNOME 社区的用户反馈了一个关于 GNOME Shell 日历服务器的 bug,此错误会影响诸如 Pop OS 19.10 和 Fedora 31 等发行版。反馈中提到 GNOME Shell 日历服务器的 CPU 占用率长期为 20~25%。此外,每隔 2、3 秒CPU 使用量会骤然升高一次。无论是对于 CPU,还是笔记本电脑的电池寿命,该错误都会给它们造成很大的影响。好在问题目前已经被解决。 反馈者将这个 bug 定位到了日历服务器中不断重启的 ECalClientView-s 服务中,并提供了许多关于此问题的详细信息、火焰图,还有不少其他用户表示在其他发行版上也遇到了同样的问题。 GNOME 开发团队成员通过与多位遇到此问题的用户进行沟通,得到了更为详细的错误信息,并于几个星期前提交了解决该问题的补丁,不过直到近日才被合并。据团队成员介绍,此前的代码在收到任何关于 ECalClientView 的变更后,始终会重启整个 ECalClientView,从而导致不断重复地重启视图。最新提交的补丁通过正确使用 ECalClientView 修复了问题,并提升了性能。 下一...
- 下一篇
PESCMS Ticket 客服工单系统 v1.3.3 发布
我们很高兴地宣布PESCMS Ticket v1.3.3 的到来。此版本带来了应用插件开发工具和修复常规BUG。 新功能 应用插件开发工具 为了更好地让大家开发PESCMS应用插件,我们本次更新添加了应用插件开发工具。同时,我们也将应用插件开发的完整文档编写完毕了。马上开始阅读吧:《应用插件开发指引》 改进 本次更新主要为修复常规BUG,详情如下: 修复弹窗在table中样式异常的问题。 修复微信公众号登录账号与系统的账号审核设置机制不一致的问题。 修复微信公众号登录账号时,选择直接登录没有选择默认客户分组的问题。 修复手机访问后台,工单发起转派获取客服成员异常的问题。 修复前台登录注册相关页面中,关于密码长度的提示指引异常问题。 修复我的工单不显示工单状态的问题。 待修复的问题 客服在工单进行转派时,发送的通知{user_name}标签没有转变为上一任客服名字的问题。 应用插件相关 除了新增应用插件开发工具,本次还对应用插件进行如下调整: 应用插件注册事件支持占位符。 应用插件补充install()方法。以便应用在首次安装时,部署初始化的必要文件。 控制器增加应用插件URL生成方法p...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Hadoop3单机部署,实现最简伪集群
- CentOS8编译安装MySQL8.0.19
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Mario游戏-低调大师作品
- CentOS6,CentOS7官方镜像安装Oracle11G