Nodejs 为什么 left-pad 只有 11 行代码，也能成为众多库的依赖？

发布于 1周前 作者 wuwangju 来自 nodejs/Nestjs

Nodejs 为什么 left-pad 只有 11 行代码，也能成为众多库的依赖？

首先申明，本人没怎么写过 JS …

https://github.com/azer/left-pad

不算空行的话， left-pad 真的只有 11 行，当然再处理一下可能几行就搞定了。

那么问题来了，为什么这么短的代码，也能成为众多库比如 RN 的依赖？

难度人们已经懒到这种程度了？


Harmonyos Next教程
53 回复

http://www.v2ex.com/t/265944#reply0


有点意思。


感觉我在 “以己之矛攻己之盾”

这是很好的，看看 SICP 第一章。

让自己的代码只做最重要的事。
这儿一个 11 行，那一个 11 行，多了之后弄个 utils ，臃肿，也不专注。

是的～模块化本身就是人懒。。有什么不好的嘛

npm 的小模块哲学

这是多米诺骨。。。首先开始写一个项目的用了这个包再发包，然后另一个程序猿用了这个程序猿的包，再另一个程序猿，如此往复下去，你就会发现某个大型项目居然会有你的包，而你的包出问题有可能导致整个项目挂掉，说到底所谓 unix 哲学虽然讲究只做好一件小事然后集合小事办大事，但是某个人对于这么多所有的小事是无法掌控的，

然而懒才是发展的第一驱动力



然而我敢说 Node.js 中 100% coverage 是最多的。。。

假设我需要处理字串了
首先我要先去 google 搜索一下应该用什么包
然后我要看看这个包应该怎么调用，至少要读一遍 readme 吧
然后 install ，写引用，写调用
怎么看也不如自己写两句话来的快啊

好吧，假设从性能考虑，毕竟 string 操作会牵涉出一大堆问题
a 包说我是 fast left pad
b 包说我 3x faster than A
c 包给出了 benchmark
…
开始晕了，我觉得还不如从算法开始调研呢

后期维护考虑，一个组件总有机会得到性能提升的吧
然而我在 golang 上的体验是，妈的这个包又不兼容了，编译不过都是给面子的，有时候得跟进包里调试，最终你会发现辣个人不经意地改了某处导致你的程序 bug

而且这边会有一个问题, 就像这次 left-pad 包挂掉一样, 如果某个深度依赖的包被黑(被黑的意思是不管你指定啥版本, 啥版本我都给污染了)
那么会不会有很大的安全风险?

如果是相对简单的包，那了解如何使用也很快，而且测试、维护成本更少。如果是实现 重要功能的模块花费更多时间熟悉也是有价值的。

Monad 定义还只有两行呢…但是绝大多数程序员都搞不懂

人家写了 11 行，你自己写真不见得只要两句话。
字符串长了是个合格的程序员总会想想效率吧，而你自己写的还得好好想想到底高效不高效。
举个例子，假如 left pad 也许有什么黑科技，用了一些普通人根本看不懂的 trick 写了个特别高效的算法，那么用的人肯定很多，你用大家都用的就得了，管那么多干啥，反正至少不比你自己写慢。
然后你觉得这个算法不可能有黑科技，那大多数人怎么知道没有，确定“没有”更好的算法要求的功力根本不比知道更好的算法低。
用库的话基本上至少库里面那部分都是“优秀”的，你自己写的话不能保证，就这么简单。。

如果这次不是 11 行的 left-pad 而是 1100 行的大包被撤了引起恐慌是不是你就不会问这个问题了？

我引 11 行的三方库和引 1100 行的三方库有区别吗？都是为了解决我的问题而已。




在我看来这样的代码可能使用 Gist 更合适。

现在是一行（ N 多 NPM 包不包括头尾，只有一行），你确保以后为了兼容不会变成多行？
然而，我们为什么要关心实现它需要多少行，直接使用它就好了。
让它变成一个黑盒，通过项目本身大覆盖的测试用例保证可用性

前端毕竟走在潮流前端，新时代的搬运工。
11 行的包都需要引入，都不用考虑整个项目的掌控问题吗？

这样的 gist 多了以后需要来个谁统一管理一下不？

对于那么多昨天出设计图今天出模板明天晚上就要上线的产品还真没那么多时间考虑这些…

楼上们，请问多少行才能作为包？

如果是我的话，这样的代码更偏向于直接拷贝到项目中，不是很喜欢很多依赖，对项目的掌控性更强吧。

1 行

复用代码， npm 就是为了这种需求才存在的

有道理

这个库优秀在哪了

当然有区别， 1 === 10000?

懒癌，现在随随便便安装一个模块， node_modules 里面全是一大堆的依赖。

left-pad ：怪我咯

我还真不知道有这种东西，我都是自己手写的。

然后我自己写的是给一个 block 加 left pad 的……比他不知道高到那里去了 /w\

拷贝到自己的项目当然可以了。
然而上游的错误修复你来跟进？
一个项目引用十几个小包全部你来跟进，那上班还要干其他活么。
如果特别闲的话当然是可以这么做的。

NPM 是辣鸡，现在开始使用 Twitter 作为包管理系统

https://gist.github.com/rauchg/5b032c2c2166e4e36713

这要权衡利弊吧。没有足够的理由说服我自己能引用这样的库到项目里。而且出了错自己也能很快定位。

没说他优秀。
我是说你尽量都用库“一般来说”“至少”不会比自己写的差。
而且在某个你认为很简单的没几行的库里面，你很可能已经享受到大神写的算法带来的好处，这种没必要去一一鉴别，只需要从统计角度来说用库更有好处就足够了。

公共的东西提取出来模块化对构建大型软件有帮助。
就算是你自己写一份，通常也是提倡封装成单个 library 或者库的，也就是像这位库作者一样单独拉出一个项目来。

我想起了有个 twitter-sort

其实要做类比的话， left-pad 可能就是 Apache Commons 里面的一个方法而已…

然后这条推被删了就懵逼了 23333

先不说 NPM 。若在多个项目之间有复用模块的需求，只是 copy-paste 到代码里面，有修改的时候每个项目都要改一次，你不希望让维护更简单高效吗？

NPM 可以是一种方案，怕被撤了被黑了或想要掌控的话可以自建 registry 。

不过主题说的意思貌似是 LOC < x && ‘too simple’ 所以是否应成为模块。这个 1L 可解答。

理解错了还望指正。

我多加了几行代码： https://github.com/ZhangHang-z/string-pad (/ □ )

第三方的包真不是随便就可用的啊

https://github.com/tjmehta/is-positive-integer


| Version | 1.0.0 | 2.0.0 | 3.0.0 | 3.1.0 |
|---------------------------|-------|-------|-------|-------|
| isPositive(1) | true | true | true | true |
| isPositive(0) | true | false | false | false |
| isPositive(new Number(1)) | error | error | false | true |

来源 https://www.reddit.com/r/programming/comments/4bjss2/an_11_line_npm_package_called_leftpad_with_only/d19vysi

面向 github 编程的核心思想，能找现成的绝不自己写，)手动斜眼笑

说到底就是 javascript 缺少 std 库呗


赞同，进步起源于懒。

依赖是种病， node 社区可能没救了…

JavaScript 的锅 (逃…



嘿嘿嘿…

为了兼容多那几行，你真的用得到吗？反过来说，如果用得到，你有为它写测试用例吗？如果没有写测试用例，你怎么知道兼容那几行不会破坏你现有的代码？如果你写测试用例，你以前为什么没有测它呢？

你的意思是 left-pad 和 monad 存在相似性所以可以拿来类比？

不能，纯吐槽，抽象程度与代码量无关

在Node.js生态中，left-pad虽然只有11行代码，但其功能简单且实用，因此被众多库所依赖。以下是对其成为众多库依赖的原因分析：

  1. 功能明确：left-pad的功能是在字符串的左侧填充指定的字符，直到字符串达到指定的长度。这种操作在文本处理、日志记录等场景中非常常见。

  2. 代码简洁：其实现代码非常简洁，没有冗余的逻辑和复杂的依赖，这使得它易于理解和使用。

  3. NPM生态的依赖关系：在Node.js中，项目通常依赖于多个NPM包，而这些包之间又可能相互依赖。left-pad可能因为被某个核心包依赖，进而被整个生态链中的多个包所依赖。

  4. 社区信任与广泛使用：尽管left-pad包很小，但由于其开源性质和在社区中的广泛使用，它积累了一定的信任度。许多开发者在构建新项目时，会倾向于使用已经被广泛验证和使用的库。

以下是一个简单的left-pad实现示例：

function leftpad(str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

总之，left-pad虽然代码简短，但其功能实用且符合NPM生态的依赖关系，因此成为了众多库的依赖。

回到顶部