Hacker News Reader

Hacker News

Comment by Macha | Hacker News Reader

Parent Full thread

Macha

I'm not sure how to avoid this sometimes.

I have a Rust project I've been working on.

It has dependencies for:

axum: the web framework in use

serde, serde_json: Serialization of API responses

sqlx: To talk to sqlite

time: Standard datetime format with localisation and serde support

tera: templating

tracing: async logging

uuid: UUID generation

Of these, I feel they're reasonable dependencies. You could maybe quibble about uuid (which itself only depends on rng + serde with the features I've enabled), or tracing maybe, but they provide clear value.

Anyway, those direct dependencies expand out to 300-odd transitive dependencies.

So what do I do? Do I write a templating engine, HTTP server implementation, SQLite driver and JSON library from scratch to build my little ebook manager?

View on HN

300 is nothing compared to the typical Node project. It's typical for a basic React project to have over 14,000 dependencies.

Can you please source this? A react project can be so many things...do you mean create react app? A custom react app?

create-react-app starts with 1506 deps:

    $ npx create-react-app my-app
    $ find my-app/node_modules -name package.json | wc -l
        1506

90% of which are development tools - eslint, testing, typescript, webpack, etc.

The actual runtime dependencies of a react app are basically just react and react-dom.

Are dependencies that run on your development machine any less of a maintenance or security concern?

No, but the number being quoted is the sum of two different security concerns - and it’s attributing the concern to ‘react apps’, when actually react itself is pretty clean in terms of dependencies.

Yes, because they aren't running in prod.

300-odd seems reasonable (or at least unavoidable, given modern realities). JS projects typically have much more, and additionally, you don't even get deduplication of modules, so you may have three different versions of the same module on disk.

I don't think you can reason about quality in a modern Javascript project. Keeping a close eye on thousands or tens of thousands of modules isn't practical.

If Software Engineers were more like "real" engineers (ie PEs) they could never sign off on a project built like this.

Browsers recently implemented uuid natively, not sure if that’s a js spec change but do check :)

Doesn't help in this case, since it's server side code.

Hex/base64 encoding of some bytes from system random isn't sufficient, it needs to be UUID parseable format specifically?

Aside from that, I guess your other dependencies have the same problem. It's not enough for one person to be mindful if they need something fully reasonable like a web server library which then depends on a million packages to build from source. Often-used dependencies could

- work like a regular package system (e.g. Debian's) and distribute (reproducible) binaries unless explicitly asked to build from source,

- only pull optional dependencies when they're used (a web server might depend on a logrotate dependency but maybe you don't use on-disk logs at all)

- and/or be more selective in what they depend on.

None of these are quick and easy to do without downsides

Reply on news.ycombinator.com