Multi-repo setups induce a lot of overhead, especially if you don't already have people on your team who know how to manage them. Monorepo setups are just /easier/ on average. To illustrate, here's a simple situation you might run into: you're attempting to upgrade two software components at the same time. For a multi-repo: you open up PRs with the updates for each repo, great. Now you want to test that the two PRs work correctly together. So you might have a third repository with integration tests that can stand up both components with references to your other repositories via submodules. You create a branch on your integration testing repository and check out the appropriate branches of each submodule. You'll also need to keep these submodules updated whenever you update the corresponding PRs. If both updates need to be atomic then you'll need something to make sure both PRs are merged before any releases get cut. You'll have to start throwing some serious automation on top of all of this or it'll become too annoying to manage. For a monorepo: you create one PR with changes to both components. All of your tests run within the monorepo.
Our challenges with multiple repos mostly revolved around builds and orchestration. We had to apply all build/deploy changes to all repos, and that increased the chance of doing some small thing wrong. Finding what exactly is wrong with one repo that should be the same as all the others was like one of those "find the differences" pictures. Really annoying.
This is more microservices than multi repo related, but making sure all the different services are released in sync was hard and annoying and often caused issues. Eg a specific API was updated and released but the for a consumer had to be rolled back and the rolled back version wasn't compatible with the new API. So current version and roll back wasnt an option. Rolling back the API would require rolling back all consumers but crap, one of the consumers applied a big migration to our core database and rolling that bank would take forever. And so on.
Just tons of little edge cases that went wrong at the worst time because it was so hard to foresee all the issues.
Monorepo and monolith is so comfy. Want to share code? Move it up one or two directories and import from there. No issues with two bundled react versions in two builds. Easy to refer to code from other teams, never an issue that someone forgot to add you to that one repo almost no one uses but that you need to commit to during firefighting.
I'm not saying multi repos/micro services can't work, but it's hard - you need strong processes that prevent people from being lazy, you need monitoring and management well defined, you need extra tooling that's aware of the repo structure, you need a strong story around migrations, and so much more.
I currently work with a mono repo monolith that over a thousand devs contribute to daily and it's Cindy comfy. It feels much easier to fix too many devs in one repo (primarily via strong compartmentalization) than to fix too many repos/services
If I am working on a bigger project with multiple smaller projects I create a folder structure locally anyway!
I can commit them too and when pulling I can just choose to only pull the one submodule instead of all of them?
Working on them is essentially the same, you just need to update the main repo once in a while or run git pull independently.
Nothing is worse than half-baked monorepo solution.
Monrepos can encourage a lot of good practices and can provide some pretty large benefits which is why many large engineering orgs gravitate to them. But most of those orgs have the capacity to absorb the tooling costs they bring as well.
I am a part of the team behind it, so AMA about the tool :-)
What does this mean?
>* We are debating between a using a monorepo or multi-repo strategy*
Why? What's the debate like?
Complexity doesn't go away, it's moved to another layer :)