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

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

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

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

"faker": "^5.5.3"

这样写,构建时,npm就会自动找最新的小版本,然后进行依赖升级,即隐式依赖升级。隐式依赖升级看似让开发者更“专注于业务开发”,然而我们通常会忘记隐式依赖升级的假设:假设1:版本之间是相互兼容的;假设2:认为远程的源代码库是永久稳定的。当依赖是源代码依赖时,问题会暴露更彻底。

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

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

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

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

  1. 禁止隐式升级
  2. 所有的依赖都必须从私有仓库拉取

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

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

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

发表评论

登录后才能评论
网站客服
网站客服
申请收录 侵权处理
分享本页
返回顶部