The premise of the article and the usage of the word and concept of "monorepo" used by many organizations is misguided. A monorepo is not just a bunch of proje

The premise of the article and the usage of the word and concept of "monorepo" used by many organizations is misguided. A monorepo is not just a bunch of projects thrown together into one repo. It's the philosophy of having all code of a bigger organization in one repository. When smaller teams inside of companies start creating "monorepos" for a hand full of projects, they end up with many "monorepos". This approach combines the worst of both worlds: you get the tooling complexity and scalability problems of monorepo combined with the inability to make atomic changes over multiple projects. You get none of the benefits. If you are thinking about moving to a monorepo, do it in a way that - has everything required to build a deployable unit into the repo, no dependencies to other repos - under no circumstances have code in another repo depend on code inside the monorepo - avoids ending up with dozens of monorepos