Hacker News Reader

Comment by tqkxzugoaupvwqr | Hacker News Reader

> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old.

We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.

View on HN

I'm sure you have a lived experience that guides what you said, but this just hasnt been my experience.

We just use dependabot to issue PRs for updating dependencies, and we merge automatically when tests pass. It's never caused an issue.

I actually have dependabot enabled on a side project that I've stopped maintaining and every once in a while I get package update notifications.

It works great but the underlying problem still remains I guess

In curious why you feel the need to do that? I typically only update dependencies either for serious security issues or new features I really, really want to use.

I still have a few projects running Webpack 1 without issue.

Large companies often have security mandates that dependencies should be regularly updated.

Well, sure. Dogmatic policies like that will cause all kinds of problems.

I used to do this on rails projects. Then 3 years later you're running all ancient libraries, and you need to upgrade one with dependencies that conflict with your older locked versions. So now instead of dealing with one thing at a time, I've got 30 libraries (many not even direct dependencies) that have all got to get upgraded, and it's a nightmare to unwind and update it all.

Why not just use fixed versions and upgrade when you have a reason to?

That sounds like a nightmare waiting to happen. You have a package which hasn't been upgraded by your team for two years and suddenly someone finds a vulnerability in every version before 3.xyz.something. When you check, your version package is 1.3.5. Now you have to upgrade multiple major versions, and in all likelihood the package had transitive dependencies which have had many updates themselves as well. After several months/years of neglect, "upgrade when you have a reason to" has turned into a major undertaking and if you are especially unlucky it will take multiple devs many weeks to sort out the mess. All this time, your app will be running an unsafe version of the package and you can only hope that nobody finds out before the dependency upgrade is completed.

Keeping your dependencies is boring and takes a lot of time, but the alternatives are far worse.

Another option is to ditch the dependency and roll your own, which for many things will be Good Enough(TM), especially as the JS standard library becomes more useful.

Like, do you really need to import half of lodash or ramda just so you can one-line a few calls?

I try to be judicious about adding dependencies, but Lodash is very well-understood and stable. It's actually the type I would add without any concerns whatsoever. I can't even remember hitting an issue due to it making a breaking change.

Or just backport the fix

“Why not just”…

I sincerely do not understand this complaint. Do you dislike bug fixes and new features? Would you be happier with a stagnant tooling ecosystem?

Sadly it’s the constant barrage of breaking changes. It’s not just a version number bump and everything keeps running. Patch version breaks the app. Minor version breaks the app. Major version breaks the app (understandable in semver) but multiple inter-dependencies need to be updated in parallel.

So part of my job is maintaining a complex webpack build system, and I do get that it's not a small amount of work. However, the changes I see aren't wonton. They're typically aimed toward a world that's more interoperable and more standards-compliant.

For instance, Webpack 5 deprecated worker-loader in favor of a construction using new URL() and import.meta.url. Adopting this was a huge pain, but what we get in exchange is a system that can load workers using standard syntactic constructions that work under e.g. our test runner or in a NodeJS microservice. Something like that is worth the hassle to me.

As for minor and patch versions causing breaking changes, this has happened to me a few times. Terser Webpack Plugin 3.0.6 exposed flaws in a custom Webpack plugin we'd written for internal use, which I cannot fairly blame on anybody but ourselves. Babel 7.5 broke CommonJS targets in a way that wasn't fixed until 7.6, which was truly unpleasant and something I hope to never deal with again. TypeScript doesn't use Semver and usually has breaking changes in every point release. For the most part, however, semver has proven trustworthy.

The Darwinian foment that characterizes the front-end ecosystem has created the best tools I've ever used. When I look at the quality of tooling available on stacks that prioritize stability, I am not jealous.

I maintain oodles of npm packages, several of which enjoy over 5 million weekly downloads. They have dependencies, and I cannot support your claims.

Sure - some packages in the ecosystem will not follow semver, some will let breaking changes sneak in where they aren't supposed to be. But you'll find this in any pluggable or package manager ecosystem. Please, measure your frustration and choose not to paint with such a wide brush.

If you want things to be more stable use clojure

Reply on news.ycombinator.com