> if you can't have one commit in production at any given time That might be possible in a simple library + 1 consumer scenario if you follow the other comment

> if you can't have one commit in production at any given time That might be possible in a simple library + 1 consumer scenario if you follow the other commentors' recommendation to always update library + consumer at once. But in many cases you can't, anyway, because you're deploying several artifacts or services from your monorepo, not just one. So while "1 commit in production at any given time" is certainly neat, it wouldn't strike me as the primary goal of a monorepo. See also this discussion about atomicity of changes further up: https://news.ycombinator.com/item?id=44119585 https://news.ycombinator.com/item?id=44119585 > what advantages for the monorepo remain? Many, in my opinion. Discoverability, being able to track & version all inter-project dependencies in git, homogeneity of tooling, … See also my other comment further up on common pains associated with polyrepos, pains that you typically don't experience in monorepos: https://news.ycombinator.com/item?id=44121696 https://news.ycombinator.com/item?id=44121696 Of course, nothing's free. Monorepos have their costs, too. But as I mention in the above comment and also in https://news.ycombinator.com/item?id=44121851 https://news.ycombinator.com/item?id=44121851, a polyrepo just distributes those costs and makes them less visible.