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