@chuck Monorepos have one use case, which in the experience of many developers is the only relevant one: when you just want a modular structure in your code, but effectively deliver a single monolithic product.
There are many, many constellations in which that's not true.
And then, this is also highly dependent on your implementation language and build/packaging system. Some languages make modules and packages largely equivalent. A monorepo is actually overkill here.
@freakazoid @chuck You know how they say exceptions prove the rule? You know that you just picked the two biggest exceptions?
@freakazoid @chuck That's fair.
All I'm trying to get at is that mentioning an unusual counter example or two doesn't substantially alter the rule. But I'm also not going to pretend that this rule must absolutely apply everywhere, just... as a rule.
Google AFAIK doesn't actually have everything in a huge monorepo. I have never worked there, but I guess could ask. I wonder how representative the Android (AOSP) is.
Here, they use https://android.googlesource.com/tools/repo ...
@freakazoid @chuck ... which is explicitly *not* working on a monorepo, but used to orchestrate multiple individual repos as one.
I guess from a usage point of view, it acts like a monorepo, but it still allows composition of individual repos into one such virtual monorepo.
I really wonder how representative it is. Gotta ask my insiders 🤔
