Advantages of Monorepos (2015)

> With a monorepo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way. Using a single repo also reduces overhead from managing dependencies. This is the major thing I miss about Subversion, and the fact that in Subversion a subdirectory in a repository can be checked out on its own. At the top level of…

It's very simple: with a monorepo you always have access to everything you need, together with a ton of stuff you don't. Whether or not this is advantageous boils down to whether the cost of not having access to something you need is greater than the cost of having access to a bunch of stuff you don't. As long as your system is reasonably efficient at letting you select small subsets of everything you could potentially have access to, the…

I view the repo as the unit of versioning. If something has its own release cycle with its own semver number, it should be in its own repo, and vice versa. Monorepos make sense if your whole site is at a single version, as in the article. But if you want to have libraries that have stable versions (which I find useful, because it allows teams to own codebases - and I find maven is much much better than this…

> Since atomic cross-project commits are possible, the repository can always be in a consistent state – at commit #X, all project builds should work. At Google this regularly failed. We spent hours unable to commit changes (unless a disaster could justify ignoring build and test failures) because someone we'd never met had broken the world and the fix was still making its way through the enormous backlog of projects to retry. Every project needed people taking turns in a…