从软件工程角度看Faker.js作者删库事件

0f9f5e8965b8118114aa510ef5500246.png

faker.js和colors.js是前端工程中非常出名的开源仓库。就在几天前,原作者Marak Squires把自己的库全删除了。引起了行业的广泛讨论。

笔者看到这样的事件,脑袋里第一件事想的就是node的依赖管理问题,应该被暴露出来了吧。

因为笔者见过太多的人,在node工程中依赖从来不指定具体的版本。比如:

"faker": "^5.5.3"

这样写,构建时,npm就会自动找最新的小版本,然后进行依赖升级,即隐式依赖升级。隐式依赖升级看似让开发者更“专注于业务开发”,然而我们通常会忘记隐式依赖升级的假设:

假设1:版本之间是相互兼容的;

假设2:认为远程的源代码库是永久稳定的。当依赖是源代码依赖时,问题会暴露更彻底。

假设1,前端开发人员应该非常有体会了,我就不想细说了。而假设2,这次事件,足以证明这个假设(有时)是不成立的。这两个假设前提就是前端构建的不确定性因素。

然而,有人会说了,这两个假设大概率成立的。

我想说的是,如果你希望做的是“工程”,而不是手工修修补补的软件,你就必须尽可能的消除不确定性。

作为软件企业,那如何消除这两个不确定性呢?

  1. 禁止隐式升级

  2. 所有的依赖都必须从私有仓库拉取

实际操作方式就是在构建流水线中加入对于以上两点的校验。

最后,看到这样的事件,还是非常的理解作者的。个人认为,他有权力这么做,毕竟,开源不开源是他自己的事。我也相信他也没有求大家使用他的库。

另,多说一句,这样的事件,会不会在Golang的生态圈发生?(悄悄地告诉你,已经发生过类似的了)

欢迎关注:持续交付实践指南 公众号

最后,大家可以看看,之前写过的,关于前端构建的文章:

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值