
JavaScript Developers: The New Kings of Software - lolptdr
http://thefullstack.xyz/javascript-developers/
======
bootload
_" npm is the bigger than any other package manager of any language."_

that isn't necessarily good, cf: _" Kill Your Dependencies"_
[https://news.ycombinator.com/item?id=11065769](https://news.ycombinator.com/item?id=11065769)

~~~
stephenr
how many of those npm packages exist because a js developer didn't want to
use/know about an existing shell command so s/he created a node shell script?

And how many are tiny little packages that provide a single piece of
functionality that other languages either include in the standard library or
bundle up with related functions?

I laugh and cry every time someone says npm is a good package manager.

I recently had to help a client debug why their angular(I think?) front end
wasn't working in safari or Firefox. Turns out they were (via various
packages) requiring 9 different copies of a package that just handles parsing
query strings, and at v6.0 it went to let/const syntax and broke browsers.

That package was created 18 months ago (July 2014) and is already at 6.x.

I don't do js dev these days but if I did, npm would be the last resort for
me.

~~~
btdiehr
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
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
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.

~~~
stephenr
"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!?

