Ask HN: What are the pros / cons of using monorepos? • Hacker News Board

Re: Ask HN: What are the pros / cons of using monorepos?

#41

Post by lallysingh » Thu, Oct 08, 2020, 4:07 PM UTC

ht85 wrote: post #26

lallysingh wrote: post #2

Pros: * Single version / branching for everything * Commits that go across components/apps are atomic. Cons: * When it gets big, those features matter less * Churn from other dev's stuff gets in your merge/rebase work. * 'git log' and other commands can be painfully slow * Mistakes in the repo (e.g., committing a password) now affect many more people. Use for highly-coupled source bases. Where releases together and a…

> Churn from other dev's stuff gets in your merge/rebase work Wouldn't other people' work only cause issues if they are changing the same files, in which case conflicts would happen even if the work is spread in multiple repos?

Good point. I've gotten hit by this in monorepos but I probably just tried to merge instead of rebase. Both are crazy painful on large source bases.

It still takes forever!

I should replace that with 'most commits in history are irrelevant to you, so you have to dig smarter to understand what's been going on with your components'

Re: Ask HN: What are the pros / cons of using monorepos?

#42

Post by nendroid » Thu, Oct 08, 2020, 4:07 PM UTC

Always use a monorepo.

There is zero difference between using repos to organize things or using folders to organize things, except for the fact that updated dependencies across repos require extra steps to update if they change. More repos = more annoyance.

Use folders to organize things because common sense.

Additionally, don't use classes to organize your code, use combinators.

Folders and combinators will solve basically imo 95 percent of all organizational problems related to design.

Things like micoservices, multiple repos, and Gof design patterns only serve to make the organizational problem worse.

Re: Ask HN: What are the pros / cons of using monorepos?

#43

Post by hinkley » Thu, Oct 08, 2020, 4:09 PM UTC

dcolkitt wrote: post #10

For me the biggest pro and con are the same thing. With a monorepo your respective projects' codebases become tightly coupled. Why that can be a bad thing? Good software engineering practices tend to be associated with loose coupling, modularity and small, well-defined interface boundaries. Putting each project into its own repo, encourages developers to think of it as a standalone product that will be consumed by th…

If a monorepo is generating multiple binaries, there’s no reason it can’t use separate compilation units. In many languages, separate compilation units give you that arm’s length separation you need, without introducing the problem of making breaking changes that you can’t reasonably detect prior to commit, because the code is used in some obscure module you don’t even have checked out.

For that reason, monorepos favor the new programmer, which makes it easier to ramp your team size.

Re: Ask HN: What are the pros / cons of using monorepos?

#44

Post by detaro » Thu, Oct 08, 2020, 4:09 PM UTC

bweitzman wrote: post #30

bbotond wrote: post #6

I don't have a lot of experience with monorepos but I've found them very useful for: - Simple projects with a server and an SPA component - frontend and backend code for the same feature is on the same feature branch, can be tested and reviewed together. - Projects with a couple of microservices that share some common libraries - these libs can be directly referenced by the microservices instead of being published on…

If you don't publish packages anywhere, wouldn't that mean that if you update some library with a breaking change, you have to update all call sites? Maybe the fix for that is to never make breaking changes, but that has drawbacks as well...

It's a tradeoff. Yes, you can only remove something if all callsites are gone, need to take care of breaking changes etc, but on the other hand you have clear insight into that and individual components can't as easily drag behind and require you to keep old versions around/maybe even backport fixes/...

And ideally a monorepo workflow gives you the tools to a) find all callsites, b) run tests to ensure your changes won't break anything, c) apply changes in lockstep. Those tools are an engineering effort, but the equivalents for a large multi-repo setup are too.

Re: Ask HN: What are the pros / cons of using monorepos?

#45

Post by gravypod » Thu, Oct 08, 2020, 4:09 PM UTC

methyl wrote: post #32

dinkleberg wrote: post #9

Mono repos can be useful if you have different services that are highly dependent on each other. This lets you package releases in a simple way by just tagging the repo. That tag/release gives you the exact version of all the components that you need. But CI becomes substantially more complicated. You have to figure out with every commit what actually changed and based on that change what needs to be tested and built…

> You have to figure out with every commit what actually changed and based on that change what needs to be tested and built. I feel this problem and I wonder, is there any ready-made solution for that?

Google, Twitter, and Facebook have open sourced their solutions to this. Bazel, Pants, and Buck. Each have some rough edges but I'm currently migrating a bunch of stuff to Bazel and the workflow and tooling for it is pretty amazing.

Re: Ask HN: What are the pros / cons of using monorepos?

#46

Post by gen220 » Thu, Oct 08, 2020, 4:11 PM UTC

I've worked in environments across the version-control gamut. The best-run places have had monorepos. But, for the life of me, I would not trust the companies that didn't have monorepos, to operate a monorepo.

To go mono is to make an org-level engineering/cultural commitment, that you're going to invest in build tools, dependency graph management, third-party vendoring, trunk-driven development, and ci/cd infrastructure.

Can you make a mono repo work without all of those things? Yes, but you are sacrificing most of its benefits.

If your eng org cannot afford to make those investments (i.e. headcount is middling but there is zero business tolerance for investing in developer experience, or the company is old and the eng org is best described as a disconnected graph), forcing a monorepo is probably not the right idea for you.

Monorepo vs microrepos is analogous in some ways to static vs dynamic typing debate. A well-managed monorepo prevents entire classes of problems, as does static typing. Dynamic typing has much lower table stakes for a "running program", as do microrepos.

edit:

It's worth noting that open source solutions to build tooling, dependency graph management, etc. have gotten extremely good in the last 10 years. At my present company (eng headcount ~200), we spend about 2 engineers-per-year on upgrades and maintenance of this infrastructure. These tools are still quite complex, but the table stakes for a monorepo are lower today than they were 10 years ago.

Re: Ask HN: What are the pros / cons of using monorepos?

#47

Post by gravypod » Thu, Oct 08, 2020, 4:14 PM UTC

x87678r wrote: post #18

Do people big monorepo's always clone the whole thing? Our CI/CD (TeamCity) always seems to check out the whole repo even if you want just one sub directory.

Gitlab CI does a single clone of each repo per runner executor and then does fetch/clean for subsequent builds. It's pretty quick in our use cases.

Re: Ask HN: What are the pros / cons of using monorepos?

#48

Post by AlphaSite » Thu, Oct 08, 2020, 4:14 PM UTC

methyl wrote: post #32

dinkleberg wrote: post #9

Mono repos can be useful if you have different services that are highly dependent on each other. This lets you package releases in a simple way by just tagging the repo. That tag/release gives you the exact version of all the components that you need. But CI becomes substantially more complicated. You have to figure out with every commit what actually changed and based on that change what needs to be tested and built…

> You have to figure out with every commit what actually changed and based on that change what needs to be tested and built. I feel this problem and I wonder, is there any ready-made solution for that?

Bazel? Gradle? They’re good at figuring out the minimal changeset and caching very aggressively.

Re: Ask HN: What are the pros / cons of using monorepos?

#49

Post by jayd16 » Thu, Oct 08, 2020, 4:14 PM UTC

Pros:

- You can track changes across projects.

- Finding source for a project can be easier.

- You can more easily switch to code dependency instead of binary dependency. With things like gradle becoming able to pull and build git commits this is less of a win.

- Its easier to kick off downstream builds because everything is in the monorepo and you can more easily track dependencies.

Cons:

- Its a technical challenge. Git isn't great at it although its getting better.

- If you do want to lean into linking source instead of binaries you now need to have a more consistent build system across your codebases.

I prefer working in them and in my opinions its approaching a personal preference choice.

Re: Ask HN: What are the pros / cons of using monorepos?

#50

Post by minor3rd » Thu, Oct 08, 2020, 4:16 PM UTC

methyl wrote: post #32

dinkleberg wrote: post #9

Mono repos can be useful if you have different services that are highly dependent on each other. This lets you package releases in a simple way by just tagging the repo. That tag/release gives you the exact version of all the components that you need. But CI becomes substantially more complicated. You have to figure out with every commit what actually changed and based on that change what needs to be tested and built…

> You have to figure out with every commit what actually changed and based on that change what needs to be tested and built. I feel this problem and I wonder, is there any ready-made solution for that?

We just build and test everything every time. Maybe it costs us more $$$ on CI, but it costs far less in developer time. That being said, I mostly work at startups and larger companies will certainly cross a threshold where this isn't feasible.