Hacker News Reader

Comment by Waterluvian | Hacker News Reader

When I start a project I get whatever `npm install` returns. I freeze it. And then I only change it if one of a few things happens:

1. npm warns me of security issues

2. A new feature exists that I need

3. I've profiled and am seeking performance improvements

I used to just push everything forward on a regular basis in fear that I'd fall too far behind but I stopped doing that at some point and discovered that it doesn't really manifest as a problem. Chasing bugs and features usually keeps relevant packages current. Also the discipline not to depend on too many top-level dependencies.

View on HN

...until you discover the feature you wanted is two major versions after yours, and you’ll spend days updating to the major version because you did not care to update. (eg reacr-router)

I'm happy to pay that cost once at one time than incrementally and may have never needed it.

That one-time cost is at least an order of magnitude greater than the sum of the many-time costs, in my own experience. And that’s before you run into tangential problems like increased time to respond to security issues.

Further, I would bet a large sum of money that the overwhelming majority of vulnerabilities discovered and patched in open-source libraries are never officially reported and never have a CVE or OSVDB entry; they are simply patched in situ with no announcement or fanfare.

Got to be at least partially offset by the likelihood of new code/major rewrites introducing vulns. Kinda curious how the numbers work out on this. Best to install patch updates but hold off on major versions by default?

This is what I generally advocate. Pin to a major version and ruthlessly update. Major versions are fine to delay until an opportune time, but never to the point where you're even close to being more than one major version behind.

Client: "What do you mean it will cost X money and Y time to fix this trivial bug/feature in our App? And whats this babbling about having to upgrade at least a dozen frameworks? I just want this simple thing changed, not have my entire App rebuild. Last time you did that everything else broke and it took forever to get all the new bugs sorted."

It’s the same as premature optimization

Or worse: find out you need a security fix and that a large dependency chain is more than one major version behind. The issue is publically known and easy to scan for. The clock is ticking...

the dependency is open source ya?

if upgrading is that bad can always (usually) patch it yourself

That would be your own fault for using immature libraries that don't offer stable versions with security and bug fixes. Unfortunately that's most of the npm library and a growing problem in other ecosystems.

I commented with a realistic and common use case in mind. We can talk idealistic / paranoid scenarios too, but that's just not how majority of developers work, so it's a bit of a moot point.

> We can talk idealistic / paranoid scenarios too

Have we sunk that low that the idea of using mature, stable and supported libraries is idealistic and paranoid now? It used to just be called responsible.

> but that's just not how majority of developers work, so it's a bit of a moot point

I don't think identifying the root cause of an issue is ever a moot point.

YAGNI (at least until YNI)?

I think that's good reason to do some research on the main packages your rely on.

I've been burned by react-router more than once, so for my last few projects I went for a much older, stabler package (I think it was page.js). I didn't impact my project much, but saved me from dealing with the react-router hell of tight coupling with react combined with a history of ridiculous non-backwards-compatible updates.

npm doesn't auto update major versions by default anyway. So you will likely need to spend the same amount of work but during unscheduled time, updating code for features you didn't even need yet. It can be very disruptive to work in progress.

Reply on news.ycombinator.com