> This seems exactly wrong to me. Getting rid of complicated deployment lifecycles is exactly the job that people use monorepos to solve. Wasn't that one of the reasons they are used at Google, Facebook, etc? As well as being able to do large-scale refactors in one place, of course.
No, neither of those is why big companies use monorepos. Clearly the kinds of things you wrote are why the general public thinks big companies use monorepos, which is why this argument keeps popping up. But given making atomic changes to tens, hundreds, or thousands of projects does not actually match the normal workflows used by those companies, it cannot be the real reason.
Monorepos are nice due to trunk based development, and a shared view of the current code base. Not due to the capability of making cross-cutting changes in one go.
You do not need Monorepos for trunk based development. In principle you "only" need a common build system. E.g. You can just force the consumption of head via the build system. I think the rollback is still a factor. E.g. in a Monorepo rolling back a change is straightforward, whereas with multiple repos you would have to somehow track that commits from several repos belong together. This would create an additional layer which is avoided by using a monorepo
Without a mono repo and the ability to build from HEAD all the components, it's much harder to be sure a change to a library _is_ actually backwards compatible (think a complicated refactoring).
Otherwise, there is much more fear that a change to an important library will have downstream impact and when the impact does arise, you've moved on from the change that caused it.
No, neither of those is why big companies use monorepos. Clearly the kinds of things you wrote are why the general public thinks big companies use monorepos, which is why this argument keeps popping up. But given making atomic changes to tens, hundreds, or thousands of projects does not actually match the normal workflows used by those companies, it cannot be the real reason.
Monorepos are nice due to trunk based development, and a shared view of the current code base. Not due to the capability of making cross-cutting changes in one go.