Our code base has grown organically and its internal dependencies are very complex. We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, the idea that the scaling constraints of our source control system should dictate our code structure just doesn’t sit well with us.

This is from the blogpost it links near the beginning. Also worth a read if you’re interested.

If I had to guess I’d say it’s because fundamentally Facebook development is about deploying servers.

As you move through the main branch, at any commit, you should have something that you can deploy. The moment you split the repo you lose this, and need to worry about keeping multiple repos aligned.

I personally love a monorepo. It has to be managed effectively by the team, but the benefits are great. Most of it boils down to making more effective incentives for maintenance and care for downstream effects because “we all live here”. There are tradeoffs and it’s not for every situation or team though, for certain.