You must log in or # to comment.
The only reason monorepos are used is because tooling for multi-repos is inadequate, or people don’t know how to use it.
Version control tooling is still at its “blackberry” stage anyway.
It’s really all about using Conway’s Law to your own benefit.
If adding features or fixing bugs consistently requires one person from a fairly small team to make PRs across multiple repos and changes can only really be tested in a staging environment where everything can be tested together, then it’s an anti-pattern.
However, if 100 developers or more are working in a single repo, it’s past time to split it up into appropriate bounded contexts and allow smaller teams to take ownership.
I worked at a place where hundreds of developers worked on a single Rails monolith / monorepo, and enterprise architects insisted that 100,000+ RSpec tests that required PostgreSQL had to run in CI for every PR merge. Every build took 45 minutes and used ungodly amounts of cloud compute. The company ended up building their own custom CI system to reduce their 7 figure CI spend so they could ignore the problem.
They are simpler, but they do not scale. Eventually its better to create an internal package repo to share common code, this allows rolling updates a lot easier than a monorepo does.
Smaller repos are also less stressful for monitoring and deployment tooling and makes granular reporting easier which you will eventually have to do in large projects.
Simple for small code bases, a pain and a big code smell for large ones.
I mean, with large swaths of big tech companies running monorepos, does this statement really stand up to scrutiny?
For one data point, Google has >2 billion slocs in their monorepo.
Agree with this explanation. Also in a monorepo it’s much easier to reference code between modules and I think this leads to too much coupled code. It takes more discipline to limit the scope of modules.
We have a gigantic monorepo at work.
To manage the complexity we have entire teams dedicated to aspects of it, and an insanely complex build system that makes use of remote builders and caches. A change to a single python file requires about fifteen seconds of the build system determining it needs to do no work, with all of this caching, and the cache can be invalidated unexpectedly and take twenty minutes instead. Ordinary language features in ides are routinely broken, I assume because of the difficulty of maintaining an index of that stuff on such a huge codebase. Ordinary tools like grep -R or find can only be used with care.
grep
consider looking at ripgrep and semantic search tools.
i maintain a gigantic monorepo using policies, cicd gating, pre-commit, and lots of scripting. its not unworkable, just takes process. i don’t really agree with the creators pov. but i guess i may not be a new engineer entering a team with a monolith and a bone.
I don’t see how ripgrep would help with the monorepo situation. We have tooling for an equivalent of grep, but it’s based on an index, not what’s on your filesystem.
The thing to me is always that, yeah, you need a huge commit for a breaking change in an internal library inside a monorepo, but you will still need to do the same work in a polyrepo eventually, too.
Especially since “eventually” really means “ASAP” here. Without going through the breaking change, you can’t benefit from non-breaking changes either and the complexity of your codebase increases the longer you defer the upgrade, because different parts of your application have different behavior then. So, even in a polyrepo, you ideally upgrade all library consumers right away, like you’re forced to in a monorepo.
This is true but there is a matter of being able to split up work into multiple pieces easily and prioritise between services. E.g. the piece of legacy service that nobody likes to touch, has no tests and is used for 2% of traffic can take its’ time getting sorted out without blocking all the other services moving on.
You still have to do it and it should be ASAP, but there are more options on how to manage it.
The problem is PRs / CI tooling. They treat a repo as an independent project, but…:
- A change needs to be able to span multiple repos
- …or you need a way of expressing dependencies between changes in multiple repos
- …and you need to be able to block changes to dependencies that should be non-breaking but aren’t.
Zuul CI solved a lot of these kind of problems for the Openstack project but I’ve personally found it a bitch to setup. Lots of good ideas in it though.
