In the very first sentence the author asserts that:
"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."
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'll transition off.
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't provide real value to the business, and it'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.
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?
The article says that all the good things of monorepos can be done elsewhere, but doesn'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'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)
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.