Keynote: Why Monorepos
summary
Monorepos claim faster, more reliable engineering by letting tools compute an affected graph and run builds or tests only for changed projects, using computation caching and distributed execution to avoid full-repo CI. The history traces 2005–2022 and a move from trunk to polyrepos to structured monorepos; Nx (five years of work), Lerna, Turborepo and Bazel are cited as practical implementations. A single version policy reduces dependency drift, and a bug fix workflow shows immediate integration and no separate publishing step, short-circuiting the weeks-long polyrepo cycle.
AI-written summary · about
chapters (10)
- 0:00Intro
- 1:23Way back in 2005, trunks ruled the world
- 2:03Monolithic Anarchy
- 3:18Rising Popularity of Continuous Integration Higher quality software Build times increased as code base grew
- 3:59Git and GitHub Lightweight version control, with a service to match
- 4:33Npm and semver Robust package manager, and a versioning scheme to match
- 6:13But polyrepos come with costs - Late integration of - High setup overhead per Difficulty contributing outside of my repo - Overall complexity increases exponentialy with versioning
- 8:01Polyrepo outcomes Significant duplication of code - Inconsistency of UV/UX across teams - Silos
- 8:47Recently, a few things have happened to shift back to monorepos Teams wanting more cross- collaboration -Product owners wanting more consistency Tooling to remove the pains of monorepo
- 11:07No solves the biggest challenges of working in a monorepo: Fast
related talks
19mKeynote: Why Monorepos
46mExploring the power of monorepos: When and why to use them
29mMonorepos, are they right for you?
30mPoly Monorepos, the Best of the Two Worlds
31mThe monorepo: self-organising codebases and automatic scaling
50mScaling Monorepos
41mHandling Monorepos Today
28mKeynote - Nx and Lerna: Integrated vs Package-Based Monorepos