Hacker News Reader

Comment by drifkin | Hacker News Reader

I've been working on a lot of node stuff and lately I've been noticing how crazy big some of the dependency trees end up becoming. So I just did a quick check on ghost: currently there are 487 total dependencies in the dep tree when you do an `npm install ghost`

To be fair, there is some overlap. For example, "debug", a fairly common package, is included in various parts of the tree 8 times, though there are 3 distinct versions being used.

(Keep in mind these numbers are not including dev dependencies. If we add those in, the tree balloons to over 1,400 dependencies!)

View on HN

The issue with the node ecosystem is that they (we?) have really taken the mantra of "Do one thing and do it well" to heart. Most of the dependencies you load are tiny and only do one thing.

Whether that's ultimately a good thing, I don't know. Maybe NPM is just too explicit in showing you everything that you installed.

But there's now this shrinkwrap thing now that promises to slim down those huge dependency trees. I haven't played with it too much yet, but smells promising.

Shrinkwrap doesn't slim down the trees, it just makes sure the whole tree is locked to specific version, so your Linux server doesn't end up installing a different version of some package than your Mac does.

You might be thinking of npm 3, where modules are installed at the top of the tree first, and there's only extra copies of a module down the three if something specifically needs a different version of that module.

The issue is that the Node ecosystem embraces not sharing libraries so you end up with n^2 growth in packages for size. There are lots of small Ruby gems, but you can only require one version of a Ruby gem per runtime so it keeps things much smaller.

But also much more fragile. I've spent far too many hours in dependency hell on ruby / java projects when 2 packages required different versions of another package and you have to continually fiddle with versions to get them all working smoothly. I love that NPM packages have their own dependency tree so you're never stuck in that situation.

Automatic dependency resolution a-la Ruby's bundler should be required for any respectable dependency manager. In my experience, the algorithm nearly always automatically finds a successful set of dependencies, and when it doesn't, it is because I really have incompatibility that requires code changes in one dependency or another, and further verification. That isn't "dependency hell", it's just the reality that upgrades to one set of interfaces often require changes in another set that depends on them.

I never have problems with Ruby any more. Unless the gem is using the FFI or something weird it everything almost always works. In fact I've had way more problems with Node than with anything else.

Reply on news.ycombinator.com