Monorepo Is a Bad Idea

I respectfully disagree with this. Assuming you have the right build system and tooling setup a monorepo is strictly better than the alternatives solely from the code reuse and cross-stack visibility gains you get.

In the very first sentence the author asserts that:<p>&quot;There’s this concept in the industry that all successful companies use monorepos, so in order to become as successful as them, yours should too.&quot;<p>I have never heard this notion uttered anywhere previously and I have been closely following the Mono-Repo-Not-Mono-Repo controversy for several years.

Despite the limitations mentioned in this article, my team prefers a monorepo. I said, if you have a better way for us to administrate this, please start a discussion. If the pros outweigh the cons, we&#x27;ll transition off.<p>Under the old model (non-monorepo), you merge and release one repo. Then you have to open a pull request in another repo to do a dependency bump. That step is busy work that doesn&#x27;t provide real value to the business, and it&#x27;s something you need to regularly if all of your repos are being actively developed.

I disagree with some of the points. I think something between mono and multi is good. If you have multiple independent products or multiple independent dev teams, they should probably have their own repo.<p>We had 30 odd services in a multi repo setup, we recently moved them all to a mono repo. The new mono repo structure so much easier to work with.

Why is monorepo a bad idea?<p>The article says that all the good things of monorepos can be done elsewhere, but doesn&#x27;t say what monorepos are bad, except that the author thinks it is bad that a monorepo lets you easily test a change all your software at once instead of letting you ship broken code that is only noticed at runtime.

If you think about how DVCS works, it&#x27;s all blobby-things connected together with tree-ish things. Keeping all your blobby-things in one place lets you connect them more flexibly with tree-ish things and enforce stricter consistency (in the consistency model sense)