&quot;Easy&quot; should not be the primary goal of a package manager.<p>Someone releasing (I say releasing and not maintaining, because I&#x27;m certain a good number of the npm packages available are effectively unmaintained) a package should be sufficiently aware of both the language and the package manager itself to understand how they work.<p>In my earlier tale I mentioned a package that was included 9 times. I <i>tried</i> to dig into finding why the various dependencies have such old versions, but I gave up in sake of my own sanity when I discovered this scenario:<p>The project requires 47 packages at the top level, 33 of which have exact version match requirements.<p>One of the dependencies is `grunt-contrib-watch` with an exact version requirement of 0.6.1.<p>That package has a dependency on `tiny-lr-fork` with yet another exact version requirement of 0.0.5. But it gets worse, because `tiny-lr-fork` (as the name suggests) is a fork of an older package called `tiny-lr` which was unmaintained for a while. But now, `tiny-lr` is <i>more</i> up-to-date than the fork is (and more confusingly, the `fork` npmjs page points to the upstream github repo, NOT the fork repo).<p>And that is where we find our dependency on `qs` with a &quot;approximate&quot; (as npm calls it) version requirement of ~0.5.2<p>I actually dug a little further with a one-liner I found to identify (and count) the duplicated dependencies from the tree: 120 unique packages, the highest dupe count is 24. TWENTY FOUR copies of the same module, again ranging from 0.X releases to 3.x.<p>The node_modules directory is 200MB. The entire back-end application that actually makes the fucking thing work, is 1.1MB.<p>Are you FUCKING KIDDING ME!?