3 ms·
The whole point of a monorepo is to force you to update all of the consumers, and to realize that breaking changes are expensive. The two monorepo ways to do t
by spankalee 1y ago
The whole point of a monorepo is to force you to update all of the consumers, and to realize that breaking changes are expensive.
The two monorepo ways to do this:
1. Use automated refactoring tools that now work because it's one repo
2. Add the new behavior, migrate incrementally, then remove the old behavior
- baq 1y ago> force you to update all of the consumers, and to realize that breaking changes are expensive. ...and the article points out correctly that it's a lie anyway, but at least you can find all the consumers easily.
- spankalee 1y agoThe article is not correct on that point. At Google we would create release branches to fix the monorepo at a predictable point for testing, and only cherry-pick what we need during the release process. I'm sure others do similarly, because there is no way you would allow arbitrary changes to creep in the middle of a multi-service rollout.
- baq 1y agoThe multi-service staggered rollout is the reason the article is correct unless you are tolerating contract mismatches somehow other than in the code. not at google so won't be guessing.
- cloogshicer 1y agoThanks for the info! Seems like a big restriction to me.
- bluGill 1y agoBoth of those work in polyrepo. You need a tools team to make it happen though, just like monorepo needs a tool team. The tools needed are different but you still need them.
- eddd-ddde 1y agoIn a polyrepo it is more common that the update simply happens, now repo A depends on v1 and repo B depends on v2, then a year has passed and repo A doesn't even remember they still depend on an old insecure library.
- bluGill 1y agoThat is a downside of a polyreop that you will need to figure out how to mitigate. It doesn't matter if you go monorepo or polyrepo you wil have issues as your project grows. You will need to mitigate those issues somehow.
- kccqzy 1y agoIn a polyrepo it is common to say I depend on this specific git SHA of that other repo. In a monorepo it is weird and unheard of to say I depend on this specific SHA of the current repo. It's a matter of defaults.
- bluGill 1y agoIn a polyrepo you need to figure out how/when to update those SHAs. This is one of the hard things about polyrepos. Monorepo of course doesn't need that concept because you cannot depend on some previous state of the repo.
- marcosdumay 1y agoWith enough tooling, a monorepo or a polyrepo environment look exactly the same. Those articles are "Look. This is a good way to organize your code", not something that tells you one of those is better than the other.
- spankalee 1y agoMost monorepos imply that all first-party code only available at one version. Polyrepos usually allow first-party code to depend on old versions of other first-party code.