One company I worked for had a bot that would periodically go and try to upgrade each individual app dependency, then see if everything built and passed tests.

If it got a green build, it would make a PR with the upgrades, which you could then either choose to merge, or tell the bot to STFU about that dependency (or optionally, STFU until $SOME_NEWER_VERSION or higher is available, or there's a security issue with the current version).

If not, it would send a complain-y email to the dev team about it, which we could either silence or address by manually doing the upgrade.

This worked out rather well for us. I think the net effect of having the bot was to make sure we devs actually paid attention to what versions of our dependencies we were using.

The solution was, and always been, to have someone review every commit to the libraries that your app uses, and raise red flags for security vulnerabilities and breaking changes to your application.

Oh, boy, I would love to work for a company that has someone like that. Know of any? At the least, I would love for a company to just give me time to review library changes with any sort of detail.

> It’s just a matter of figuring out which manner has the better value to risk trade off

This is also bad.

If you want to have both stability/reliability and also receive security updates you need somebody to track security issues and selectively backport patches.

This is what some Linux distribution do. Mainly Debian, Ubuntu, paid versions of SuSE and Red Had and so on

The sweet spot would be using a lock file for reproducible builds, and programmed dependency upgrades. Before the dependency upgrade you can check if the new version breaks something and plan for it.

I've used this in Python, where I try to keep dependencies to a minimum. I don't know if that would work in JavaScript, the dependency tree is huge there.