很多人不理解 NPM 上 left-pad 这样的模块的意义

其实我的理解不就是 OOP 的东西么？把所有东西都一个个做成模块，然后需要的时候就可以用，尤其是哪些常用的东西。

这些东西是一行还是几行，放模块里调用起来肯定比你自己再写一遍要方便的多。

当然，这些东西是自己写一个模块在那还是调用现有的，我觉得这部是重要的。不重复造轮子固然重要，但是去找这些轮子也比较花时间的（除非你已经知道的或者很流行的）不过我觉得这部是讨论的重点。

重点是，这个东西好用，可以完成我需要的功能，我不需要重新写了，而且我可以反复利用，正好还被我知道了。

@SharkIng 模块和 OOP 有什么必然联系？

function noop() {}

把 one line 变成 two lines 就可以完美避开这个问题了。机智不。

@keyanzhang 优秀的 stdlib 也不能完全覆盖所有的边角问题，就像很多其他语言程序员写多了之后都有自己的一个 stdlib-exts 一样。

然而一个 stdlib-exts 拆成几十个包的做法确实让人理解不能。

我觉得这不是懒的问题，而是程序就应该这样写。一段代码，一种方式是自己写，另一种方式是用第三方库，并且是被广泛应用且证明可靠的库，那么必然要用第三方库。
如果第三方库看起来不是那么可靠，那么如果可能，就去 improve 这个库，然后再用。
如果人人都这样做，那将会产生个完美的社区，和完美的开发环境。
软件的成本中，写代码的成本是比较小的，调试和测试才是占大头，既然已经有可靠的代码可以复用，那为什么还要自己写呢？不管多短的代码，自己写都有可能犯错不是？
回想一下，你难道没有犯过让自己捶胸顿足的低级错误？

这次的事件，不是 do one thing and do it well 原则出了问题，而是社区管理的问题。不能因此而不让小的包存在。

这么短的代码，是直接复制过来，还是引入外部依赖呢？
我觉得引入模块就一个好处：标准化

解决的方案可以是多人维护一库，像 underscore 一样，把这些功能集成进去，包引用也减小不少

@sunjourney 然而那已经让 underscore 闲得很臃肿了，现在 lodash 的做法是自己本身包含所有功能但是每个功能同时以 lodash.xxx 的名字发布。

根本就是 js 缺乏一个像样的标准库，发展出这种畸形的依赖，还能衍生出一套理所应当的设计哲学出来，那句话怎么说来着，不以为耻，反以为荣？

@sox 那是因为 js 作为一种要优化到最小的包存在，却缺乏有效的只集成需要的 function ，所以在工程上智能自己做拆分。

如果是可以使用 require('lodash') 的同时处理优化，谁在开发的时候还会喜欢去依赖一堆 lodash.xxx ？目前有一些工具在做，但是还是尝试性的。在正式项目中使用还有点担忧。

@iwege 如果可以那样的话，为什么不直接只需要一个标准库 require('all') 然后自动分析用到的代码，然而不是做不到吗

[autocomplete by stackoverflow]( https://emilschutte.com/stackoverflow-autocomplete/)

@iwege P.S. 你可以尝试 rollup/webpack2 的 tree shaking 功能，但是依赖 ES6 的 import 特性。

@Mattsive talk is less

@sox 我最后不是说了么，有一些工具在做了.... 所以我不是很理解你说的做不到是什么意思.... 不管依赖什么，终归还是有人在特定条件下尝试性做了....

@iwege 我的意思是始终要依赖构建工具

开源是把双刃剑

说到底就是专业级地实现轮子并维护轮子麻烦 有人帮你搞了何乐而不为？

如果是产品依赖这种库也没有什么问题. 和几行代码没关系, 只关乎你自己是否觉得这样 ok.

但是如果我是 library vendor, 一般如果不是真的非常必须的话, 我不会加入任何第三方的依赖进去. 如果一定要依赖的话, 那也会直接把源码 embed 到我的 library 里面去.

当然, 我这是在有着非常不错的 std library 支持的情况下. JS 的世界好像很不一样的感觉.