我们在NPM中达到了100万个包大关——NPM是Node.js中事实上的包管理器。相信我，其中大约有30%左右的包都在做同样的事情。
过去
早期，Node.js是一个简单的运行时，但由于缺少库而受到限制，但是随着时间的流逝，越来越多的人开始制作工具、库甚至是Cloud IDE。Node.js引发了一场革命，即JavaScript不再局限于浏览器中，而且它擅长于此。
但随着时间的推移，Node.js变得更加健壮，并开始走在浏览器的前面——这是一个新的JavaScript生态系统，它不受供应商缺乏的ECMAScript支持的限制。随着时间的流逝，一些古老的库变得越来越陈旧。
但这和NPM软件包有什么关系呢？
问题是，在那些早期的日子里，也有包污染 （其今天仍然是一个问题），那里有更多无用的包比有目的的东西更多。他们中的一些人甚至重新发明了轮子，在某些包中被丢弃了将近6年。
在这个例子中，我们对Redis有不同的包，Redis已经有一段时间没有维护了（不过grunt包没有维护还是可以理解的，因为它们已经被取代了），而且大部分都是你可以在app-level的实现中做的事情，显然不需要使用该程序包。
因此，停止重新发明轮子，除非你需要
假设你发明了一个记录仪，很酷！你想让人们用它，更酷！
但是，让我提醒你，总有成千上万的库可以做同样的事情，所以如果你的记录仪是特定领域的，不要尝试着把它做成NPM包，把它放在你打算使用它的项目里就可以了。
只有在某些情况下，你才需要真正地为每个人的利益发明轮子——因为目前的公共库表现不佳，或者说普遍的不好。
停止制造毫无用处的包
认真一点，停下来。你在破坏软件包仓库的意义，它是项目要使用的可重用模块的仓库。我不在乎它是否是一个笑话包，你是在浪费对象存储，而它本来可以由一个更有用的模块占用的。
我们有像Maven和PackageCloud这样健全的包仓库，那么为什么我们不能像它们一样专业和健全呢？我们和他们没有什么不同。
总结
NPM和JavaScript社区是我们现在所说的“现代网络”的推动力。但如果我们一直做无用功，一直误解了运行时有包管理器的概念，那么我们就会成为一个包管理器不应该成为的榜样。
所以，让我们尝试着改变一下库编写的思路——只有在没有办法的情况下，或者目前的实现方式对广大网友来说非常吃不消的时候，才去做一些东西。如果你做的东西是针对特定领域的项目，那就完全不要去做了。
