Monorepos: Any Size Fits All
summary
Monorepos remove npm packaging steps so a library change is made, tested and committed alongside affected apps in one go, speeding deliveries for teams of 1–15, 15–70/100, and 100+ people. They enable TypeScript path aliases, enforce a single version policy, and let tooling build an nx dependency graph to compute which projects CI must run on so only the impacted apps rebuild (affected-project CI). Trade-offs include trunk‑based flow, preferring release branches for hotfixes and using CODEOWNERS for directory-level permissions.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:24The best way to organize repos
- 2:01What is a monorepo
- 3:02The organization size pyramid
- 4:08Code reuse
- 7:44The single version policy
- 10:28Intergration and the impact of tooling
- 12:51Safe refactors
- 13:57Trade-offs when considering a monorepo
- 16:37Tooling options
- 18:01Conclusion
related talks
29mUnderstanding Monorepos: What you need to know
29mMonorepos, are they right for you?
46mExploring the power of monorepos: When and why to use them
19mKeynote: Why Monorepos
50mScaling Monorepos
01h 18mPanel: Monorepos — Pros and Cons
31mThe monorepo: self-organising codebases and automatic scaling
01h 03mMonorepo – How to do frontend faster, better and safer