It’s not problem specific to monorepos: if one of your in-house libs is in its own repo and someone broken it for iOS, and for some reason (like in article) you absolutely must use broken version to build against Android, you have to do branching too. Except if you publish versions to private package registry and ios and android apps that use that lib are in separate repos.
At work, we have this problem regularly, as we have collection of libs in repo shared between projects, linked as submodule.
Monorepo can be beneficial here, as you’ll detect that ios build is broken sooner. Usually you will not bother merging broken branches.
modularity
Here monorepo might be more helpful. For modularity, you need well-defined API with no unwanted coupling. For example, you are using ruby, so API boundaries are blurry and couplings are easily introduced, even with transitive dependencies. You make some change that you think affects only private API, but in reality it breaks public API, and you’ll notice it sooner, because it’s monorepo and your lib is tested against all its users. API boundary becames clearer and you can create new test case in lib itself.
tooling
Chances that monorepo in your company will be not as large as in Google. If you currently have checkouts of all your separate repos, you’ll have no problems merging that in monorepo.
I thought about using monorepo, but the main stopping point for me is build system that tracks dependencies between targets, including tests, like Google’s Bazel. If tests are ran in previous build, and tested piece of code and its dependencies are unchanged, these tests are not ran again. It requires germeticity and reproducible builds. Almost impossible for e.g. Rails app and regular CI.
I’m working on a moderately large C++ codebase right now (one of the products of my company, we have several others).
I find it very, very painful to switch branches repeatedly because of different dependencies, libraries, generated code, etc.pp
So the easy way out is to have a few checkouts. Right now I have like 5 of them that I use in a given week (sometimes testing small things on a release branch, sometimes features, etcpp). Each of them has 4GB. I don’t even want to imagine if this was a monorepo, my laptop SSD is full all the time anyway.
But yeah, not an unsolvable problem with better hardware (or better development practices) but not all companies are willing to throw hardware at developers when they ask.
If you’re using git, git-worktree is a nice way to check out multiple branches and have them all refer to one .git metadata directory, thus saving disk space.
It’s not problem specific to monorepos: if one of your in-house libs is in its own repo and someone broken it for iOS, and for some reason (like in article) you absolutely must use broken version to build against Android, you have to do branching too. Except if you publish versions to private package registry and ios and android apps that use that lib are in separate repos.
At work, we have this problem regularly, as we have collection of libs in repo shared between projects, linked as submodule.
Monorepo can be beneficial here, as you’ll detect that ios build is broken sooner. Usually you will not bother merging broken branches.
Here monorepo might be more helpful. For modularity, you need well-defined API with no unwanted coupling. For example, you are using ruby, so API boundaries are blurry and couplings are easily introduced, even with transitive dependencies. You make some change that you think affects only private API, but in reality it breaks public API, and you’ll notice it sooner, because it’s monorepo and your lib is tested against all its users. API boundary becames clearer and you can create new test case in lib itself.
Chances that monorepo in your company will be not as large as in Google. If you currently have checkouts of all your separate repos, you’ll have no problems merging that in monorepo.
I thought about using monorepo, but the main stopping point for me is build system that tracks dependencies between targets, including tests, like Google’s Bazel. If tests are ran in previous build, and tested piece of code and its dependencies are unchanged, these tests are not ran again. It requires germeticity and reproducible builds. Almost impossible for e.g. Rails app and regular CI.
That’s a really nice problem to have.
I’m working on a moderately large C++ codebase right now (one of the products of my company, we have several others).
I find it very, very painful to switch branches repeatedly because of different dependencies, libraries, generated code, etc.pp
So the easy way out is to have a few checkouts. Right now I have like 5 of them that I use in a given week (sometimes testing small things on a release branch, sometimes features, etcpp). Each of them has 4GB. I don’t even want to imagine if this was a monorepo, my laptop SSD is full all the time anyway.
But yeah, not an unsolvable problem with better hardware (or better development practices) but not all companies are willing to throw hardware at developers when they ask.
If you’re using git, git-worktree is a nice way to check out multiple branches and have them all refer to one .git metadata directory, thus saving disk space.