一个单行代码的 npm 库，竟然让数百万个 Javascript 项目崩溃了

不懂你们 JS 程序员的引用方式
难道不精确限定版本么？

package-lock.json 是多么的重要

引用这事情，感觉有点像把捅人的刀子交到了别人手上

left-pad 才过去几年，按理来说这点代码不应该自己实现吗，为什么要调用别人的库

@nyanyh 为了不重复发明轮子。

@raymanr 之前在 hn 上看到一个观点，说你同事的代码提交上来 review 了又 review，然后一个陌生人写的啥都不知道就合入然后升上去了。。。。。

@matrix67 #5 省下两行代码，却在 package.json 里多了个依赖，该有的 import 一样不能缺，没看出到底节省了什么……

我记得以前有个类似事件，也是非常短的库。我想不明白，这种一行的烂库有什么好引用的。

可以的…看着蛮吓人。不过有个问题，这种几行代码的库，你们是怎么发现的？知道是为了避免重复造轮子，但这种感觉就是一个 gist 呀，Google 一下可能就找到了。反而发现这么一个库似乎不是那么容易…

这确实是个破烂库 测也只是测大概而已
测试是否 promise 用意何在... 看来又是大而全的阴谋
小而精不重要的东西 话说也不精

有句话怎么说的来着，

有时候免费的，反而更加昂贵。

CI 应该没测试
或者没 CI
应该都不是大项目
影响也都不会大

@wangyzj #13 Angular.js 、Create React App 、Nuxt.js 算吧，影响还是有的

遇到这种事，只能一句 我屮 了。

我觉得根源还是 dependencies 的书写方式上，现在是 名称字符串：版本号字符串 这种形式，然后 npm 的 install 瞎几把下载，固定版本号没有传染性。

如果 dependencies 里面的版本号搞成对象形式，固定版本号必填，允许什么级别版本号升级兼容自己选择。那么根据最终使用如果使用的是固定版本号，安装的所有库都必须使用固定的版本号，版本的选择权就完全交给了库的使用者。传染性很重要。

说白了还是 npm 的设计有毛病。

面对过程强的地方在于只要知道过程中前后差异 只要能达成一样目的就替代掉了
弄个对象还要考虑对象相容 甚至弄个对象互转超级麻烦

@xiangyuecn 如果固定版本号，所有的库基本都无法共享同一份库了，比如 A 库用了 c 库 1.01 版本，B 库用了 c 库 1.02 版，内存和硬盘中就有二份基本差不多的重复代码了，磁盘和内存用量要爆炸一波，用处却没多少。现在的 package-lock 才是最佳选择。

只要不是写烂过程或者语言本身函式用法烂 函式好的多

@firefox12 #7 maven 还好，除了 spring 官方库不限定版本外，其他都要限定版本

golang 程序员点了个赞

@love #17 我觉得这个问题，不应该叫做问题。目测所有引用别的库的工具，都会产生此问题(他们怎么解决的我就不管了，也不懂)：

1. A 引用了 Z 的大版本 1.x，B 引用了 Z 的大版本 1.X，你引用了 AB，似乎没有问题
2. A 引用了 Z 的大版本 1.X，B 引用了 Z 的小版本 1.1，你引用了 AB，当前 Z 版本 1.2，似乎是就有问题了，是让 A 乖乖就范呢还是怎么个倒退方法
3. A 引用了 Z 的大版本 1.x，B 引用了 Z 的大版本 2.X，你引用了 AB，矛盾凸显

上次崩的好像是 isArray，同这次的 is-promise，都是数据类型判断相关的代码。

一行代码的事情要搞成几行代码，真是走火入魔啊

@xiangyuecn npm 目前是会最大可能调合合并成引用同一份代码，实在不行才会分成二份（比如引用不兼容版本）。

至于别的语言没这问题那是因为它们的库都是大粒度的，这种几十几百行代码的各个库都自己写了一份，一个项目没多少第三方库数量，不象 npm 随便一个项目就有万千上万个，这样子开发当然是很爽了，基本你要的啥工具都有。

@love 嗯，原来是这样

这个的核心问题在于 npm 默认是会改 lock 的

所以大家都来用 yarn 吧

我想起有个 npm 包是用来判断一个数字是否偶数，几百万的下载量，然后就出现另一个包，直接引用前面那个包，判断非偶数（奇数），又几百万下载量。

@baozijun 有什么区别吗？ 那些被引用的代码 你也从来没读过 没 review 过。当 spring 升级后 这些引用升级了 你会去 review 吗？ 所以和 npm 有什么区别？

npm 里面太多 one-liner 了

这不是 yarn 早就解决了么？为什么要用一个不能锁版本的软件包管理？

百行内的库绝不引用，太傻了

@nyanyh #8 别人可能花了很大精力找出的最优实现、完善的单元测试和覆盖度测试，给你带来的不应当只是「省下两行代码」

@annielong 很多你引用的库都不超过百行，你不知道而已

yarn，pnpm 解君愁
npm 也一直在进步，但是似乎没有解决这个 nodejs 设计里留下来的问题。

@firefox12
java 的基本库很丰富,不会有这种 is-number is-promise is-xxx 的几十行的库.

但是 js 的 is-number 这种库偏偏就有些必要,
因为 js 的隐式转换以及 truthy falsy 想覆盖全真的很累.

@niubee1
类型判断在 js 里面真的不是一行代码能搞定的事情
js 以及 nodejs 的官方库也是真的拉胯,太少了.

我支持这种依赖的生态. 但值得优化的地方是, 更好的标准库.

比如 `String.prototype.padStart()` 这种改进.

@yanguangs 你根本没搞清楚 核心是 review 而不是 1 行 2 行。 你一闭眼 进来了 100M Java 库，java 库开源的品质挺好，所以没问题， 而 js 呢？ 你放进来的一下子就有问题了。 本质都一样， 你都是信任发布方，自己没有真正 review 过。

真的让我 review 这 100M java 库 我也没能力。java 库 要 review jvm 要不要 review. cpu 硬件呢？ 社会效率变得无比底下。所以 这问题很难解。只不过 js 这种 实在就是太烂了。

你们 JS 圈又出这事，上一次叫啥来着 left-pad ?

@zhw2590582 这很前端，把复用做到了极致。

这个没办法，出来混总要还的。
没有技术积累， 都用开源拼拼凑凑的，这个跟裸奔没什么区别。