且听疯吟 在此记录扯淡的青春
About left-pad

前几个星期,在 npm install 的时候,不小心打错了包名,结果居然安装成功了……当时还感慨 JS 社区真是太可怕了=-=

当然这个可怕并非贬义。写过一段的 .NET 和 Erlang 之后才知道,拥有一个如此流行和活跃的社区是件多么幸福的事 😂

但是打开一个项目看的时候我是懵逼的=-= 大大小小的依赖加起来好几百个,加起来近百兆了 😂

归根到底,还是语言本身很多奇奇怪怪的行为和标准库的弱鸡,导致很多人懒得去写一个能满足任何情况并保证不出问题的「简单」功能,更别说给它加上测试

left-pad 的事情出来之后,其实我是挺佩服这个社区的。这个体系运转了这么久才因为商标的关系,而不是个人利益出现了一点问题。这依靠的是许多开发者的自律,真的挺不容易。

兹瓷不兹瓷 left-pad 存在于 npm,俨然已经成为一个新的异端之争。比如,还有人跑到我纯粹是自言自语的微博下面,就之前我感慨 JS 社区太可怕的那条微博没头没脑地把我批判一番 😂

我觉得没必要上升到那么高的高度,和兹瓷不兹瓷 one-line module 无关,单纯和 left-pad 有关
也没有人会去建立一个标准来说多少行的代码可以作为 package,这确实挺傻
我想很多人包括我自己还是承认 one-line module 带来的好处的
你甚至也可以找到一大堆理论和一堆名人名言来支持它
但是,这个世界不是运行在理想模型中的

我需要 React 这样的 package,它给我带来的好处很大,而且我不可能自己去实现它,所以就算它只有一行,我依然会用
而且它也拥有一个好爹,我也不需要去担心稳定的问题

但是这不代表我愿意去在自己项目中使用 left-pad 这样的,随时可以根据个人意愿 unpublish,并且也没有重要到需要花很大精力去替代的 package

层层依赖之下,谁会去在意最下层那个 left-pad 写得好不好,稳定不稳定?
你觉得 React Native 项目的维护者们,检查过每个依赖么?看过 left-pad 的代码么?
还是不要过于高估社区维护的可靠性了,真的
三天两头出问题的 OpenSSL 前车之鉴还在那里呢

当然,肯定有人说开源了之后,大家可以改进啊,可以提 Pull Request 啊。
别闹。
我们就拿 left-pad 来说。来,我们看看,在 unpublish 之前,有几个 Pull Request?1 个。
大部分都是这次事件之后才提出来的,有没有想到如出一辙的 OpenSSL?

我也不觉得给 npm 加上 Review 会是个好想法。
至于 npm 这种中心化的方式好不好,我只能说,大多数情况下,它解决了问题。
但是现在我们可以讨论更好的解决方式了。

归根到底,用不用 left-pad ,只是一个选择问题。
至少,我可以选择风险还是效率。