3 ms·

> Monorepos are the most common solution to enforce that behavior. Yes. This is very accurate and also the problem. Monorepos are being used as a political t

> Monorepos are the most common solution to enforce that behavior. Yes. This is very accurate and also the problem. Monorepos are being used as a political tool to change behavior, but the problem is that it has severe technical implications. > There is no "right" way. With git, there is a "wrong" way, and that's not separating your project into different repos. It causes real world technical problems, otherwise we wouldn't have this article posted in the first place. > It's just something organizations have struggle with because it's going to be costly no matter what, and all that matters is what type of cost your org is most easily able to bear. It's not a coin toss whether monorepos will have better or worse support from all standard git tooling. It will be worse every time. The amount of tooling required to enforce dependency upgrades, code styles, security checks, etc across many repos is significantly less than the amount of tooling required to successfully use a monorepo.

philosopher1234 5y ago
If you want to play right and wrong, I will say that noe it’s the right way since there is support for sparse checkouts in git. This isn’t a useful game to play.
ratww 5y ago
> The amount of tooling required to enforce dependency upgrades, code styles, security checks, etc across many repos is significantly less than the amount of tooling required to successfully use a monorepo. This is completely false. You only need extra tooling on monorepo for gigantic scale. For 90% or maybe even 99% of companies out there using version control, plain git and a "bunch of folders" is all you need, honest to god. This way you can reap most benefits and very few downsides. Detecting changes in folders is pretty easy, as most CIs/CDs have it built-in. Ff not it's easier to program a script than setup multirepo tooling.

philosopher1234 5y ago

If you want to play right and wrong, I will say that noe it’s the right way since there is support for sparse checkouts in git. This isn’t a useful game to play.

ratww 5y ago

> The amount of tooling required to enforce dependency upgrades, code styles, security checks, etc across many repos is significantly less than the amount of tooling required to successfully use a monorepo. This is completely false. You only need extra tooling on monorepo for gigantic scale. For 90% or maybe even 99% of companies out there using version control, plain git and a "bunch of folders" is all you need, honest to god. This way you can reap most benefits and very few downsides. Detecting changes in folders is pretty easy, as most CIs/CDs have it built-in. Ff not it's easier to program a script than setup multirepo tooling.