"Easy" should not be the primary goal of a package manager.
Someone releasing (I say releasing and not maintaining, because I'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.
In my earlier tale I mentioned a package that was included 9 times. I tried 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:
The project requires 47 packages at the top level, 33 of which have exact version match requirements.
One of the dependencies is `grunt-contrib-watch` with an exact version requirement of 0.6.1.
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 more up-to-date than the fork is (and more confusingly, the `fork` npmjs page points to the upstream github repo, NOT the fork repo).
And that is where we find our dependency on `qs` with a "approximate" (as npm calls it) version requirement of ~0.5.2
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.
The node_modules directory is 200MB. The entire back-end application that actually makes the fucking thing work, is 1.1MB.
Someone releasing (I say releasing and not maintaining, because I'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.
In my earlier tale I mentioned a package that was included 9 times. I tried 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:
The project requires 47 packages at the top level, 33 of which have exact version match requirements.
One of the dependencies is `grunt-contrib-watch` with an exact version requirement of 0.6.1.
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 more up-to-date than the fork is (and more confusingly, the `fork` npmjs page points to the upstream github repo, NOT the fork repo).
And that is where we find our dependency on `qs` with a "approximate" (as npm calls it) version requirement of ~0.5.2
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.
The node_modules directory is 200MB. The entire back-end application that actually makes the fucking thing work, is 1.1MB.
Are you FUCKING KIDDING ME!?