3 ms·

Is it just me or most of those "monorepo" articles are about how the company switches to monorepo then just has to fight all the problems that come up with it?

Is it just me or most of those "monorepo" articles are about how the company switches to monorepo then just has to fight all the problems that come up with it? Use multiple repos. It doesn't hurt you know. And you can have proper granularity The costs of monorepo seem to be much higher than just dealing with inter-dependencies. And you can always group projects if it makes sense

viraptor 4y ago
Obviously the articles will be about solving the problems. Nobody wants to write a "yep, the thing that worked still works well for like 99% of cases (we solved the 1% in other ways)". This of course produces bias for people reading the posts, because it's not trivial to tell if the solved problem was about to bring the company down or was just an annoyance that they solved in a cool way they want to share.
detaro 4y ago
Not like there aren't plenty problems with (and articles about) working with multiple repos. Neither is a silver bullet, you just get to pick which set of problems you prefer to have to solve (or which ones you think you can get solved due to human factors)
CJefferson 4y ago
I've never seen an article from a large company saying "we use multiple repos and it's great". Setting as all large companies seem to end up monorepo, I'm guessing in practice it is better. I'd be happy to see a counter-example, but I've not seen one yet.
- raverbashing 4y ago
  Nobody is going to write a blogpost "we use multiple repos and it's ok for us". And that is the majority of companies. Heck, even most individual developers use multiple repos. Monorepos are usually ok (and even talking about team/project granularity) until you outgrow it. Buildsystems like one-repo-per-project much better than monorepos. (Shipping a fix doesn't require rebuilding "the whole world" for example)
- jvolkman 4y ago
  Amazon I think is the notable exception to the monorepo preference at large companies. But they have no lack of their own custom tooling to make multiple repos work.
throw_m239339 4y ago
> Is it just me or most of those "monorepo" articles are about how the company switches to monorepo then just has to fight all the problems that come up with it? Seems to me that Git wasn't thought out for "monorepos" at first place as a VCS. Also, these companies should either use something else or not do monorepos.
sebastialonso 4y ago
Real world experience at the scale Uber works with, directly contradicts this, in my opinion, naive approach.
doktorhladnjak 4y ago
At sufficient scale, the problems of a monorepo tend to be more of a fixed overhead cost whereas those same problems at scale in a multi-repo approach tend to impact all engineers across the company. The fixed overhead can be addressed by hiring a dedicated team to manage the monorepo problems.

viraptor 4y ago

Obviously the articles will be about solving the problems. Nobody wants to write a "yep, the thing that worked still works well for like 99% of cases (we solved the 1% in other ways)". This of course produces bias for people reading the posts, because it's not trivial to tell if the solved problem was about to bring the company down or was just an annoyance that they solved in a cool way they want to share.

detaro 4y ago

Not like there aren't plenty problems with (and articles about) working with multiple repos. Neither is a silver bullet, you just get to pick which set of problems you prefer to have to solve (or which ones you think you can get solved due to human factors)

CJefferson 4y ago

I've never seen an article from a large company saying "we use multiple repos and it's great". Setting as all large companies seem to end up monorepo, I'm guessing in practice it is better. I'd be happy to see a counter-example, but I've not seen one yet.

raverbashing 4y ago
Nobody is going to write a blogpost "we use multiple repos and it's ok for us". And that is the majority of companies. Heck, even most individual developers use multiple repos. Monorepos are usually ok (and even talking about team/project granularity) until you outgrow it. Buildsystems like one-repo-per-project much better than monorepos. (Shipping a fix doesn't require rebuilding "the whole world" for example)
jvolkman 4y ago
Amazon I think is the notable exception to the monorepo preference at large companies. But they have no lack of their own custom tooling to make multiple repos work.

throw_m239339 4y ago

> Is it just me or most of those "monorepo" articles are about how the company switches to monorepo then just has to fight all the problems that come up with it? Seems to me that Git wasn't thought out for "monorepos" at first place as a VCS. Also, these companies should either use something else or not do monorepos.

sebastialonso 4y ago

Real world experience at the scale Uber works with, directly contradicts this, in my opinion, naive approach.

doktorhladnjak 4y ago

At sufficient scale, the problems of a monorepo tend to be more of a fixed overhead cost whereas those same problems at scale in a multi-repo approach tend to impact all engineers across the company. The fixed overhead can be addressed by hiring a dedicated team to manage the monorepo problems.