#build #monorepo
Why Mono-repo
- Using a monorepo where HEAD always points to a consistent and valid version removes the problem of tracking multiple repo versions entirely
- Static analysis can run across project boundaries without any extra work.
- Many other things, like cross-project integration testing and code search are also greatly simplified.
- You just refactor the API and all of its callers in one commit. That’s not always trivial, but it’s much easier than it would be with lots of small repos.
- Making cross-project changes is easier, tracking them is easier.
Example: Google Reader
Google Reader was discontinued!
Why It was Hard to Open-Source Google Reader?
Because of all the available libraries, it maybe took a few hours to write a simple, scalable, fault-tolerant RSS fetcher. And look, we created another library someone else inside of Google could integrate into their project. Imagine what happens when you have thousands of engineers building re-usable modules (on top of other modules) over the course of a decade.
Open source Lags Due to Multi-repo Eco-system
This sort of Lego-like development process does not happen as cleanly in the open source world.
- Some tools (e.g. Maven) do manage to make this a lot easier, at least under certain controlled conditions.
- Hosted source control (e.g. Github) has also lowered the effort required to do open source development.
Empirically, though, what it truly enabled (speculating) was a large number of small projects rather than an increase in individual project complexity.
Reference
Written with StackEdit.
