[msm_]

Interesting, i've always considered monorepo to be a maintainability win. Your code doesn't rot (as much) because it's constantly rebuilt and tested. When someone improves some downstream code (for example makes some code faster or safer) you get the benefits immediately. And most importantly - you can do huge interface-breaking refactorings on the whole codebase at once, without versioning dance. For example you can remove a parameter from some function in the library and make sure all clients still work, atomically. I think this is a huge maintainability win - as long as you actually want to maintain something and not let it rot.

But really, do you have a choice? Sooner or later someone finds a security bug in the code and you actually have to dig out the code and deploy an update.

[taeric]

The catch, of course, is a lot of the "migrate to newer versions" of some libraries brings in new features. These new features can be the source of new security concerns. Especially when added with a lot of the changes requiring some reworking on how things are used for the migration.

This would be akin to trying to move a car to a system that shuts off during stops. Totally doable, but requires a massive change in how reliant passive systems are on the serpentine belt/alternator for power.