this post was submitted on 05 Dec 2025
82 points (95.6% liked)
Programming
24039 readers
685 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Edit: Some good discussion in comments, a good one to remember is that we are talking about the common case, in a common code base people will join and leave, parts of code will start becoming abandoned, in-depth knowledge will be lost. Its easier to keep track of and learn a self contained repo with a well defined boundry rather than a folder in a large repo with no well defined boundry and possible code leaching.
From experiance i would rather not have everyone elses mistakes and forgetfulness pollute my builds, tests and PRs and pulling a giant mono repo is much more of a resource hog on your dev system.
Having defined versioning for code packages was also a nice thing to have, specially with monitoring tools to tell you when a repo starts falling behind. You dont get that with a monorepo, even if you try and enforce some form of pseudo documentation for it, time crunch will slowly chip away at the correctness of it.
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
I don't think many of us need to worry about scaling beyond the size of Google or Microsoft.