What would an optimal monorepo look like? [experiment]

TL;DR I’m embarking on a journey to set up the most productive monorepo I can.

Hi, my name is Amir :) I’ve been a software engineer at Google for about 8 years, and now I’m embarking on a journey to try and set up a codebase that’s a pleasure to work in.

Unlike most software projects where the DevEx of the development team is at most a secondary goal, in this codebase, the top goal is to make working within the codebase as productive and fun as possible.

What products am I going to develop in this codebase?
1. The tooling needed for making the codebase productive.
2. “Artificial projects” — If needed I’ll add code just for the purpose of exercising some interesting dev/deploy workflows that aren’t needed by #1.

This is an experiment, I’ll make mistakes, hopefully, I’ll learn some lessons, and maybe help others get more productive on the way.

If you’re curious about this exploration please follow me here and on Twitter (@AmirHardon). I’m going to write on my progress, dilemmas, and decisions as I go. I’d love to hear other people’s opinions and suggestions on how to get things even better.

While (at least at the beginning) I’m going to be the only one working in this codebase, I’m setting it up for a large team (as tooling and workflows for a single engineer aren’t as interesting). To make the experiment more fun and realistic I would love for other developers to work in the codebase as well, feel free to drop me a note if you want to have some code in this repository (and generally feel free to drop me a note about anything related to this experiment or developer productivity).

Monorepo vs Polyrepo?

The first decision I’m going to make is whether to keep the codebase in multiple repositories aka “polyrepos” (similar to what’s more common in the OSS world and how companies like Netflix are operating) or whether to keep everything in a single repository aka a “monorepo” (similar to how Google and Facebook operate).

The Monorepo vs Polyrepo debate has almost become a holy war with posts like Monorepos please don’t, Monorepos please do, and endless hacker threads. A read on the topic that I find informative and objective is the “Monorepos” chapter in the #FlamingoBook (which is available as a free pdf).

My take is that technically every “upside” of a monorepo can be achieved in a polyrepo setup with enough tooling investment, and vice-versa. However, I feel like achieving upsides that are typically attributed to monorepos (atomic commits, global codebase view, LSCs, global build graph, less dependency hell) is harder and less natural in a polyrepo approach.

For monorepos there’s one main challenge — scaling the version control system, it’s a big technical challenge, though it’s definitely solvable (Google has solved this with Piper, FB and Twitter are maintaining huge repositories as well).

My personal experience working in Google’s monorepo was much more productive than working in a polyrepo world (which I experienced while working on Android, Flutter, and in a startup).

So a monorepo! That’s what I’m setting up! (I’m planning and hoping to be open-minded enough to change this decision later if I realize it was a mistake).
Conveniently enough I was able to grab a very literal domain name for this exploration: amonorepo.com.

That’s it for today, I’ll be making my progress in the open and be posting and tweeting about it(@AmirHardon).