3 ms·

Could you clarify which parts of your anecdote can be attributed to `npm` in a way that's at all unique to `npm`? This story sounds like it amounts to "I saw a

by btdiehr 11y ago

Could you clarify which parts of your anecdote can be attributed to `npm` in a way that's at all unique to `npm`? This story sounds like it amounts to "I saw a bad piece of software" and "People put modules I don't like on NPM".

stephenr 11y ago
It amounts to "npm is a pig of a dependency manager and the statistics about how many packages it has are not realistic because JavaScript developers a) insist on recreating every single tool as a node script; and b) distribute the tiniest pieces of functionality via seperate packages where more sane packaging systems/communities tend to group things together logically.
- btdiehr 11y ago
  Is it not a testament to how easy NPM has made it, that it is flooded with beginners? Is that not the fate of any sufficiently popular package manager? Your disdain seems to be more about how much you dislike the javascript community than how much you dislike the tool that is NPM.
  - atomi 11y ago
    Making it easy to publish should not be a main objective for a package manager. Things like maintainability and security are more important.
  - stephenr 11y ago
    "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. Are you FUCKING KIDDING ME!?

by btdiehr 11y ago

stephenr 11y ago

It amounts to "npm is a pig of a dependency manager and the statistics about how many packages it has are not realistic because JavaScript developers a) insist on recreating every single tool as a node script; and b) distribute the tiniest pieces of functionality via seperate packages where more sane packaging systems/communities tend to group things together logically.

btdiehr 11y ago
Is it not a testament to how easy NPM has made it, that it is flooded with beginners? Is that not the fate of any sufficiently popular package manager? Your disdain seems to be more about how much you dislike the javascript community than how much you dislike the tool that is NPM.
- atomi 11y ago
  Making it easy to publish should not be a main objective for a package manager. Things like maintainability and security are more important.
- stephenr 11y ago
  "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. Are you FUCKING KIDDING ME!?