Hacker News new | ask | show | jobs
by BinaryIdiot 3781 days ago
This is a great read that can be applied to node.js very much. I've seen apps that include 10, maybe 20 dependencies but when you flatten out the full dependency tree? Thousands. It's incredible and if one of those dependencies screws up semantic versioning or just screws up in general it can be a nightmare to debug and fix.

This is why every 1.0 product I work on I include every dependency that speeds up my development. In 2.0 the first things to do is prune all unnecessary dependencies and start minor rewrites when a dependency can be done in house (yeah yeah reinventing the wheel is a problem but most npm dependencies are small and many can be recreated internally without issue).

This is even more important if you're creating a library / module. My msngr.js library uses zero dependencies and yet can make http calls in node and the browser because it was easy to implement the minimal solution I needed without bringing in dependencies to support a single way of calling http.

2 comments

The worst offender, IMO, is request. I've seen more than a few projects pull it in just to make a single HTTP call. Just look at its package.json:

https://github.com/request/request/blob/master/package.json

I'd argue the offending party is the library pulling in Request for making a few simple HTTP calls.

Request itself in my opinion is a great piece of work, it does pretty much anything one would want to do with an HTTP client.

Yes, the npm "request" module is extremely bloated and badly written, to boot. https://www.npmjs.com/package/needle is a good alternative.
Can you elaborate? How do I know Needle is any better?
Why not just use node-fetch? It's tiny.
Could you elaborate on why you view this list of dependencies as a problem?

I've been using request and its many transitive dependencies for years without hitting any real problems due to this.

This sadly also happens in some Linux repositories that add too many dependencies to a few key packages.

On NixOS, last time I tried, installing mutt ended up bringing python as well.

In Nix, it's very easy to make a minimal mutt variant by removing the python input.
Yes, but these things shouldn't be happening. Default builds of packages should be kept more minimal.

I understand it's hard with Nix philosophy, and things are improving with different package outputs. For the record, python was pulled indirectly via the gnupg dependency I think.

It's a difference in philosophy. I think packages by default should be full-featured, and minimal variants can be created for those that want it.