faker.js和colors.js是前端工程中非常出名的开源仓库。就在几天前，原作者Marak Squires把自己的库全删除了。引起了行业的广泛讨论。
笔者看到这样的事件，脑袋里第一件事想的就是node的依赖管理问题，应该被暴露出来了吧。
因为笔者见过太多的人，在node工程中依赖从来不指定具体的版本。比如：
"faker": "^5.5.3"这样写，构建时，npm就会自动找最新的小版本，然后进行依赖升级，即隐式依赖升级。隐式依赖升级看似让开发者更“专注于业务开发”，然而我们通常会忘记隐式依赖升级的假设：
假设1：版本之间是相互兼容的；
假设2：认为远程的源代码库是永久稳定的。当依赖是源代码依赖时，问题会暴露更彻底。
假设1，前端开发人员应该非常有体会了，我就不想细说了。而假设2，这次事件，足以证明这个假设（有时）是不成立的。这两个假设前提就是前端构建的不确定性因素。
然而，有人会说了，这两个假设大概率成立的。
我想说的是，如果你希望做的是“工程”，而不是手工修修补补的软件，你就必须尽可能的消除不确定性。
作为软件企业，那如何消除这两个不确定性呢？
禁止隐式升级
所有的依赖都必须从私有仓库拉取
实际操作方式就是在构建流水线中加入对于以上两点的校验。
最后，看到这样的事件，还是非常的理解作者的。个人认为，他有权力这么做，毕竟，开源不开源是他自己的事。我也相信他也没有求大家使用他的库。
另，多说一句，这样的事件，会不会在Golang的生态圈发生？（悄悄地告诉你，已经发生过类似的了）
欢迎关注：持续交付实践指南 公众号
最后，大家可以看看，之前写过的，关于前端构建的文章：
扫一扫
897
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
