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.
google does a lot of things that just aren’t realistic for the large majority of cases
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.
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.
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.
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