4 ms·

The truth is that you're not going to get to make this decision. If you're starting greenfield, you're going to start a single repo for your project. If that gr

The truth is that you're not going to get to make this decision. If you're starting greenfield, you're going to start a single repo for your project. If that greenfield is the whole company and everything is part of that project, you get a giant monorepo. If greenfield is a new division that's not part of another project, you're going to create a new repo, and now you're in a polyrepo environment. Which way it goes is determined by the environment, wherein the engineers do the sensible thing at the time. Then you do the engineering to solve the problems with whatever way you went.

icebraining 8y ago
I've started a greenfield project that involved multiple modules, and I created a different repo for each, but I could just as easily have created a single repo.
sfink 8y ago
At Mozilla, we started with a monorepo, then went to a mostly-monorepo, then consolidated just about everything back into a monorepo, and have since "decayed" a bit to a mostly-monorepo. There were major gains from merging our source tree with the continuous integration support code and configuration. We've pretty much always vendored selected third-party code, so that didn't really change. Large collections of tests and their infrastructure have been much easier to manage as part of a monorepo. Given that our tooling efforts are mostly in handling a monorepo, I can't really judge how differently things would be if we had gone full multirepo -- my experience with multirepos has been pretty awful, but that's an unfair comparison since we intentionally haven't worked on tooling for it. We solved our worst multirepo problems by going monorepo, but I'm sure other projects have solved their worst monorepo problems by going multirepo, so neither really proves anything. The push for separate repos these days mostly comes from social reasons -- if you have a separable piece and want external contributors, that's a strong motivator for putting it on github since that's just Where Things Are these days. No matter how good your tooling and issue tracking and whatever is, even if it's far superior to github's, it doesn't really matter. People have to learn yours; they already know github's. I don't particularly like github's workflow, but I still use it.

icebraining 8y ago

I've started a greenfield project that involved multiple modules, and I created a different repo for each, but I could just as easily have created a single repo.

sfink 8y ago

At Mozilla, we started with a monorepo, then went to a mostly-monorepo, then consolidated just about everything back into a monorepo, and have since "decayed" a bit to a mostly-monorepo. There were major gains from merging our source tree with the continuous integration support code and configuration. We've pretty much always vendored selected third-party code, so that didn't really change. Large collections of tests and their infrastructure have been much easier to manage as part of a monorepo. Given that our tooling efforts are mostly in handling a monorepo, I can't really judge how differently things would be if we had gone full multirepo -- my experience with multirepos has been pretty awful, but that's an unfair comparison since we intentionally haven't worked on tooling for it. We solved our worst multirepo problems by going monorepo, but I'm sure other projects have solved their worst monorepo problems by going multirepo, so neither really proves anything. The push for separate repos these days mostly comes from social reasons -- if you have a separable piece and want external contributors, that's a strong motivator for putting it on github since that's just Where Things Are these days. No matter how good your tooling and issue tracking and whatever is, even if it's far superior to github's, it doesn't really matter. People have to learn yours; they already know github's. I don't particularly like github's workflow, but I still use it.