> In my own experience, polyrepos require more tooling
That's not my experience. In my experience, polyrepo's significantly reduce complexity for a medium (30 developers) project.
An example: the following things are good software development practices if you work with a master-PR branch model:
1. Tests must pass on CI before merging a branch to master
2. Before merging a branch into master, the latest master must be merged into the branch so that tests are still reliable
This quickly becomes untenable if 30 people all commit to the same repo. By the time your PR is reviewed, it's outdated. So you merge master into your branch. By the time you come back to check your test results and merge, its outdated again. Repeat until 6 PM.
So you need partial builds to keep build time low, and would probably like to amend 1 & 2 with "unless your code has zero overlap with the changes in master". These are not standard features of any CI system I know of, hence the need for tooling.
Instead of tooling, polyrepo's provide the above benefits out-of-the-box. Just set your CI to build the repo, and it will do partial builds and PR-merging is uninfluenced by other repos. This is a huge advantage over monorepos.
The downside is that if your repos have tight coupling, you'll need simultaneous PRs in more than 1 place or need to look up history/files in more than 1 repo. If this is more than a rare occurence, this downside is so large that polyrepo is not a suitable solution for your project.
The projects of this size I've worked with did not have this problem, or the problem was solvable without much difficulty.
That's not my experience. In my experience, polyrepo's significantly reduce complexity for a medium (30 developers) project.
An example: the following things are good software development practices if you work with a master-PR branch model:
This quickly becomes untenable if 30 people all commit to the same repo. By the time your PR is reviewed, it's outdated. So you merge master into your branch. By the time you come back to check your test results and merge, its outdated again. Repeat until 6 PM.So you need partial builds to keep build time low, and would probably like to amend 1 & 2 with "unless your code has zero overlap with the changes in master". These are not standard features of any CI system I know of, hence the need for tooling.
Instead of tooling, polyrepo's provide the above benefits out-of-the-box. Just set your CI to build the repo, and it will do partial builds and PR-merging is uninfluenced by other repos. This is a huge advantage over monorepos.
The downside is that if your repos have tight coupling, you'll need simultaneous PRs in more than 1 place or need to look up history/files in more than 1 repo. If this is more than a rare occurence, this downside is so large that polyrepo is not a suitable solution for your project.
The projects of this size I've worked with did not have this problem, or the problem was solvable without much difficulty.