To me the main thing to remember is [what Joel Spolski said about rewrites](
https://www.joelonsoftware.com/2000/04/06/things-you-should-...):
"As if source code rusted. The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive."
By that token, blindly updating your dependencies sounds more like the problem and so does writing your new code in place of their old. Security patches may force your hand but apart from that, if you want stability just be deliberate about upgrading and it will be rare for old dependencies to suddenly generate new bugs.
As far I see it, the right way to think about good, reliable code is not as a compact, resilient thing like a baseball but like a matchstick sculpture glued together with maple syrup. It is both inherently very fragile and very unlikely to spontaneously break if good decisions went into the design of its supporting structures and because it's mounted to the sturdy, climate controlled plinth of the silicon chip.
In the article, these supporting structures such as compilers, OS and firmware are mentioned but if we don't trust these then we simply should all stop trusting computers. Most of us believe that this broad societal dependency has been a good tradeoff bringing us an amount of good which is so hard to outweigh even by an imagined disaster.
The same goes for most of the dependencies in the average ruby project (don't know what to say about JS). They are battle-hardened and bring value that companies would pay massive sums for were they not free.
There are of course the odd suspect, unnecessary dependencies in most projects. Usually they're for trivial uses and easy to remove. When you discover these few they do not indicate that the rest of your package list was a mistake. The fact that 90% of the problems you have come from 5% of the dependencies (made up statistic) should tell you that your project will be dead before the other 95% let you down.