79
Are monorepos really simpler?
(www.youtube.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Dec 2025
79 points (100.0% liked)
Programming
23761 readers
72 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
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.
google does a lot of things that just aren’t realistic for the large majority of cases
before kubernetes, you couldn’t just reference borg and say “well google does it” and call it a day
Yes, but that is not relevant. The person they replied to said a monorepo doesn't scale. Google (and others) prove that it does scale to at least their massive size.
most things scale if you throw enough resources at them. we generally say that things don’t scale if the majority case doesn’t scale… it costs far fewer resources to scale with multiple repos that it does to scale a monorepo, thus monorepo doesn’t scale: i’d argue even the google case proves that… they’ve already sunk so much into dev tooling to make it work… it might be beneficial to the culture (in that they like engineers to work across the entire google codebase), but it’s not a decision made because it scales: scale is an impediment
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.
that’s a good and bad thing though…
it’s easy to reference code, so it leads to tight coupling
it’s easy to reference code, so let’s pull this out into a separately testable, well-documented, reusable library
my main reason for ever using a monorepo is to separate out a bunch of shared libraries into real libraries, and still be able to have eg HMR