I'm always surprised at how often developers freeze a set of versions and leave them for a lifetime. In my past three companies I have been the only one interested in pushing dependencies on a regular basis. I always start with a massive backlog, and end up having to incrementally update from the Stone Age to $today. Once that's set and tests pass it's easy to keep things up-to-date, you end up with single-digit changes every month instead of ~100 every year.

Do it this way and save yourself the pain of zillions of updates when you HAVE to bump a package for a CVE.

Yet another case of "if it hurts, do it more often"

https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...

But the journey from A to B to C to D is longer than A to D.

You can get whiplash from conforming to every change in the winds.

This. Skipping B and C needs to be managed like any other technical debt, but it can pay off. It's not your job to regression test every intermediate version of everyone's libraries.

Word! And same for me at new jobs. I also tend to be the one who writes docs, gets testing automated, CI.

Too many developers think banging out code as fast as they can is "doing their job well".