Monorepos vs. many repos: is there a good answer? | Hacker News Reader

Monorepos vs. many repos: is there a good answer?

itnext.io

10 pointssigna118 comments

In my experience, outside Google monorepo (and maybe Meta, don't know, didn't work there) every monorepo just sucks because it's cargo culting.

It's never monorepo. It's one big repo and one or two other small repos (because of permissions, secret code, whatever), copypasted code between repos because people don't set up proper packaging, semi broken builds everywhere because of poor static analysis, and so on.

Unless you are willing to really commit (ha!) to monorepo and all the tooling and devex support that requires, just stick to multiple small repos.

Do you share code at all between the repos via package managers or just accept some duplication? Using packages requires quite a bit more discipline as maintainers need to ensure they don't break consumers. If the code is just in one big repo (maybe horrible for other reasons), all consumers have to be updated or it won't compile. It seems that using binary distribution (vs source) creates a fairly hard problem that doesn't really need to be solved.

Yeah if you actually have it all in one repo and have a good build system / tests so CI can make sure you are not breaking anything that is awesome. That is the google/bazel experience.

But I've seen "monorepos" where changes to one subfolder break the rest without developers noticing, or cases where a library / API definitions were manually copied from one repo to another instead of being properly packaged.

Well, multiple small repos is even more copy&paste then.

I find it easier to work in companies with monorepos. It’s much easier to grep for what you’re looking for. There’s no complexity hiding somewhere you don’t know about.

Whenever I work somewhere with lots of repos I create a folder called dev and clone every single repo into it.

I think to myself, “doesn’t everyone do this with multiple repos?” Then I consider some of the workflows of colleagues and have a proper realization. Overtime, unless a lot of thought is given to developer processes, the tooling becomes death by a thousand cuts. It’s a small custom configuration here, a small one-off case there, and soon it takes a day or two to setup a new developer’s machine. There are trade offs with mono repo or multiple repos. In either case a continuous revisiting of processes and optimizations is required. Unfortunately, even then, people are stubborn and will do what they know “works” even if not optimal.

You’ve hit the crux of the issue. The discussion of monorepo vs polyrepo/microservices is always a red herring. Ultimately when you unwrap it, it’s always a tooling issue. People will always have complaints and opinions about which is better, but the actual answer about which method is better is whichever method has the proper tooling built for it and that the company has bothered to take the time and effort to invest into. If the company doesn’t do that, both methods will suck. And ultimately that is, as you imply, an ongoing conversation because tooling needs grow and change for an organization over time.

Yes. Do what makes the most sense for your team size, org structure, and most importantly automation and maintenance.

Reply on news.ycombinator.com