Or are there any other aspects to the monorepo architecture that make it beneficial for large companies like that?
Just curious, I've never worked in such an environment myself.
In a standalone project, would you accept a change that is incompatible with other code in the project? For example, would you allow a colleague to change a function in a way that breaks the call sites? No, you probably would not.
The attitude within monorepo shops is that this level of rigour should be applied to the entire company. Nobody should be able to make a change anywhere if it would break anything elsewhere, or they should only be permitted to do so with intention. There are caveats to this, but that is the general idea.
- atomic PRs. All changes for a migration/feature living in one spot makes development much easier, especially when dealing with api changes and migrations
- single history. This is useful when debugging. A commit can more easily encapsulate the state of "the whole system" as opposed to a single part of it. This makes reverting, if necessary, easier
- environment consistency. updating the linting tool, formatting tool, UI library, etc is never a priority, so there's always drift, where an old repo gets stuck with old tools, dependencies and an old environment
- not shipping your org chart is easier when everyone can see and work work on the whole codebase, as easily as possible.
Example: Service A requires version 1.1 of libFoo and libFoo 1.1 requires version 0.1 of libBar. But Service A also directly uses libBar version 0.2. Now you have a conflict.
If libFoo and libBar are internal code stored in a monorepo they're automatically version-compatible because there is only one version of both.