Maybe that's a bad example, as your build can fail because of a breaking change in a dependency regardless of whether you use a statically typed language.
Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90% and at the very least I never approve a PR without happy path tests.
Refactoring from a function returning a string to another returning a string, and all compiles, yet without tests nothing works in production because it’s not the same string.
On top of that, sometimes mocking in tests also hide the string breaking change you don’t yet know about.
On top of my head, I saw this happen with a base64 string padded vs unpadded, or emojis making their way through when they did not before, etc.
So yeah, the compiler tells you which pieces of your jigsaw apparently fit together, but tests show you if you get the right picture on the jigsaw at the end (or on some regions).
> Breaking changes in dependencies end up in production only if you don't have tests.
Which are opt-in in dynamically typed languages.
You get the same functionality in statically typed languages and it's not opt-in, AND the developer doesn't have to do the work of type-checking (the compiler does it).
In a utopic scenario, yes, you fix type-checking and you can live happily ever after.
In an interoperable environment, when additional programming languages/teams are in play, which is very frequent nowadays. You have the problem of centralizing types/entities/schemas, reused types, partial types, and union types, and you can keep the story on.
At some point, instead of typing being an invisible tool, it becomes the tool. Then you superset the tool to other languages, because they are in an immutable state. Another language will emerge with dynamic typing in decades then people will take the same spiral and spend more time to reason wages.
I mean sure, if your test suite does fuzzing, then I guess so. Most test suites focus on higher level stuff like behaviours and entire features these days. This is instead of testing in isolation the technicalities like the signatures of functions and what happens if you pass a null here or there.
The same applies to type systems these days - you don't just express basics like nullable or not, you build high level business concerns into your types.
Leaking bugs, I believe, do not relate to static typing or dynamic typing; it mostly involves deployment. Your types might match, but you would still leak bugs in dependencies :/
From a CI/CD perspective, you should make sure that on updates, things won't break. As others suggest, a maintainable project would have test suites.
Except if you aim to have a program that you will never update again. Write the code once, compile it, and archive it. When you decide to keep that program available to potential clients, be prepared to back up dependencies, the OS it runs on, and everything that makes it operable. If there is a breaking change in the ecosystem of that program, it will break it.
The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes.