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

• 資深大佬 : realpg

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

• 資深大佬 : Chingim

  package-lock.json 是多么的重要

• 資深大佬 : raymanr

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

• 資深大佬 : nyanyh

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

• 主 資深大佬 : matrix67

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

• 主 資深大佬 : matrix67

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

• 資深大佬 : firefox12

  java 也一样， 几白兆的 jar maven 过来就开始跑了。

• 資深大佬 : nyanyh

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

• 資深大佬 : Kobayashi

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

• 資深大佬 : rayhy

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

• 資深大佬 : james122333

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

• 資深大佬 : XanderChen

  有句话怎么说的来着，

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

• 資深大佬 : wangyzj

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

• 資深大佬 : xunco

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

• 資深大佬 : xiangyuecn

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

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

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

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

• 資深大佬 : james122333

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

• 資深大佬 : love

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

• 資深大佬 : james122333

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

• 資深大佬 : baozijun

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

• 資深大佬 : blless

  golang 程序员点了个赞
• 資深大佬 : xiangyuecn

  @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，矛盾凸显

• 資深大佬 : DOLLOR

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

• 資深大佬 : niubee1

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

• 資深大佬 : love

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

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

• 資深大佬 : xiangyuecn

  @love 嗯，原来是这样

• 資深大佬 : Austaras

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

  所以大家都来用 yarn 吧

• 資深大佬 : zhw2590582

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

• 資深大佬 : firefox12

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

• 資深大佬 : ericgui

  npm 里面太多 one-liner 了

• 資深大佬 : msg7086

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

• 資深大佬 : annielong

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

• 資深大佬 : SilentDepth

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

• 資深大佬 : Zoro76

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

• 資深大佬 : shunia

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

• 資深大佬 : yanguangs

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

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

• 資深大佬 : yanguangs

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

• 資深大佬 : iugo

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

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

• 資深大佬 : firefox12

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

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

• 資深大佬 : charlie21

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

• 資深大佬 : enrio

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