5 ms·

Monorepo Is a Bad Idea

8 points by treypitt 6y ago

michaelgiba 6y ago
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.
mrath 6y ago
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.
- walljm 6y ago
  Same here.
tanseydavid 6y ago
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.
- castillar76 6y ago
  I've heard this a few times from cow-orkers as a rationale for doing it. "Well, Facebook does it, and Google does it." It's not a good argument in any way, shape, or form, but it's definitely out there.
gct 6y ago
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)
srtjstjsj 6y ago
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.
JMTQp8lwXL 6y ago
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.

8 points by treypitt 6y ago

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.

mrath 6y ago

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.

walljm 6y ago
Same here.

tanseydavid 6y ago

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.

castillar76 6y ago
I've heard this a few times from cow-orkers as a rationale for doing it. "Well, Facebook does it, and Google does it." It's not a good argument in any way, shape, or form, but it's definitely out there.

gct 6y ago

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)

srtjstjsj 6y ago

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.

JMTQp8lwXL 6y ago

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.