Hacker News Reader

Comment by capableweb | Hacker News Reader

> With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard.

Eh, no. You'll get shot no matter what, even if you have no gun.

For example, let's imagine you now have your version locked down codebase and after a month you want to install a new package. This one is only compatible with XYZ V1 while what you have is V2. No worries, npm will just handle that right? Well, you'll have both versions, but the prototype constructor name changed from V1 to V2, so the versions won't work together, so now you need to upgrade XYZ V1 everywhere anyways. And when XYZ did the V1->V2 upgrade, they also upgraded to GKS V53, so now you need to also do that upgrade.

Continue ad-infinitum or simply stay away from a broken ecosystem.

View on HN

This is a far bigger problem in the Java world. Maven will just pick at sort of random (it's deterministic but hard to predict and mostly invisible).

On the JS side there's a way deal with that if people use modules. Good dependencies don't clobber the global namespace. Multiple versions can exist side by side. It'll just make your build bigger.

Since the number of dependencies is way less then in the JS world, its possible to pin them down manually.

If you absolutely need to have multiple versions of the same dependency, you probably need to use OSGi.

> (...) after a month you want to install a new package.

What's your point? If you want to update a dependency then you also need to go through all their dependencies. This is not a javascript/npm problem; it's a software development problem. Dependencies don't get magically updated, even with semver. You experience the exact same problem with other tech stacks. I'm fact, I've experienced this problem far more with C++ projects than with JavaScript/typescript ones.

Why are we expecting and demanding random updates to work with JavaScript/npm when that belief and expectation was always totally unrealistic with any other stack?

The point is, that in a moderately complex Java project that might be something on the order of 150-200 dependencies, and updating just one of those usually doesn't lead to a big change in the transitive dependencies (it is a different thing for a major update, Java 8 -> 11, or from the pre jakarta JEE to jakarta), but its possible for a single person to track whats happened. But with 1500+ dependencies, so an order of magnitude bigger, its just not possible.

Reply on news.ycombinator.com