The Ingredients of a Productive Monorepo • Hacker News Board

Re: The Ingredients of a Productive Monorepo

#101

Post by bluGill » Wed, May 28, 2025, 12:16 PM UTC

cloogshicer wrote: post #67

code_biologist wrote: post #52

Earlier quoted context omitted.

That's the neat part. They don't. Either the broken consumer updates their use, you update it for them to get your change shipped, or you add some backwards compatibility approach so your breaking changes aren't breaking.

Thanks for the info! Seems like a big restriction to me.

it is the only sane thing to do. Allowing everyone to use their own fork means when a major bug is found you have to fix thousands of forks. If the bug is a security zero day you don't have time.

Re: The Ingredients of a Productive Monorepo

#102

Post by bluGill » Wed, May 28, 2025, 12:18 PM UTC

boxed wrote: post #79

The article links to a site with this definition: > A monorepo is a single repository containing multiple distinct projects, with well-defined relationships. It would be better if there were terms that delineated "one repo for the company" from "one repo per project" from "many repos for a single project".

Idealy the term would indicate code and team size. Many commenting are working on tiny projects where they don't even see the problems that cause one to think of this debate

Re: The Ingredients of a Productive Monorepo

#103

Post by cmrdporcupine » Wed, May 28, 2025, 12:19 PM UTC

bob1029 wrote: post #62

This thread is reminding me of a prior one about complexity merchants. I am seeing a lot of sentiment that there is somehow a technical sacrifice by moving to a monorepo. This is absolutely ludicrous unless you fail to grasp the power of a hierarchical file system. I don't see how a big mess like CI/CD is made easier by spreading it out to more points of configuration. To me the whole point of a monorepo is atomic co…

The push to fragmentation and atomism is so strong with this generation of devs. The obsession with microservices, dozens of small repositories, splitting everything up from fear of "monoliths."

What they're doing is creating a mass of complexity that is turning org-chart problems into future technical ones and at the same time not recognizing the intrinsic internal dependencies of the software systems they're building.

Luckily my current job is not like this, but the last one was, and I couldn't believe the wasted hours spent doing things as simple as updating the fields in a protobuf schema file.

Re: The Ingredients of a Productive Monorepo

#104

Post by cousin_it » Wed, May 28, 2025, 12:21 PM UTC

I've worked for a company with a large monorepo. At first I was a fan, but now I'm not so sure. The web of dependencies was too much. Now I think teams should be allowed to reuse other teams' code only as libraries or APIs with actual release cycles. There shouldn't be any "oh let's depend on the HEAD of this random build target somewhere else in the monorepo". There should be only "let's depend on a released version of such-and-such library or API".

If you adopt this discipline, you basically don't need a monorepo. Every team can have its own repo and depend on other stuff as third party. This adds some friction, but removes some other kinds of friction, and overall I think it's a better compromise.

Re: The Ingredients of a Productive Monorepo

#105

Post by atq2119 » Wed, May 28, 2025, 12:26 PM UTC

nssnsjsjsjs wrote: post #51

> Any operation over your repository that needs to be fast must be O(change) and not O(repo). This is a good thought! It actually needs to be O(1/commit rate) though, so that having the monorepo doesn't create long queues of commits. Or have some process batch passing ready to merge PRs into a combined PR and try to merge that. And best guess on the failing PR if it fails.

If you go the batching route, bisection on failure makes it more like O(log(1/commit rate)).

Re: The Ingredients of a Productive Monorepo

#106

Post by NiloCK » Wed, May 28, 2025, 12:27 PM UTC

amelius wrote: post #88

DanielHB wrote: post #80

Earlier quoted context omitted.

My company has been moving towards having monorepos per language stack. Decent compromise

This will start to become a problem if the stacks need to communicate with each other using versioned protocols.

Maybe I miss the point here, but it seems to me that versioning the protocols is the specific solution to maintaining interop between different implementations.

Re: The Ingredients of a Productive Monorepo

#107

Post by whstl » Wed, May 28, 2025, 12:30 PM UTC

przmk wrote: post #82

lxe wrote: post #8

So there are 2 kinds of big tech monorepos. One is the kind described in the article here: "THE" monorepo of the (mostly) entire codebase, requiring custom VCS, custom CI, and a team of 200 engineering supporting this whole thing. Uber and Meta and I guess Google do it this way now. It takes years of pain to reach to this point. It usually starts with the other kind of "monorepo": The other kind is the "multirepo mon…

At my current $dayjob, there is a backend that is split into ~11 git repos which results in a single feature being split among 4-5 merge requests and it's very annoying. We're about to begin evaluating monorepos to group them all (among other projects). What would the alternative to a monorepo be in this case, knowing that we can't bundle the repos together?

"11 repos with 4-5 merge requests" doesn't sound like Google-level, so I don't see why a monorepo wouldn't work without much work.

Re: The Ingredients of a Productive Monorepo

#108

Post by morbicer » Wed, May 28, 2025, 12:32 PM UTC

countWSS wrote: post #94

From viewpoint of security and separation of concerns giving unlimited access to everything by virtue of "everything" being stored in one giant repo sounds exceptionally short-sighted. A single rogue actor would be able to insert code to any component of choice instead of working on isolated repo with people who specifically know it and approve the code: the monorepo is a "big ball of mud" with vague shared responsib…

Codeowners file + required review from the owner team solves like 90% of those worries

Re: The Ingredients of a Productive Monorepo

#109

Post by jasminebelmont » Wed, May 28, 2025, 12:36 PM UTC

countWSS wrote: post #94

From viewpoint of security and separation of concerns giving unlimited access to everything by virtue of "everything" being stored in one giant repo sounds exceptionally short-sighted. A single rogue actor would be able to insert code to any component of choice instead of working on isolated repo with people who specifically know it and approve the code: the monorepo is a "big ball of mud" with vague shared responsib…

[flagged]

Re: The Ingredients of a Productive Monorepo

#110

Post by lolinder » Wed, May 28, 2025, 12:41 PM UTC

amelius wrote: post #88

DanielHB wrote: post #80

Earlier quoted context omitted.

My company has been moving towards having monorepos per language stack. Decent compromise

This will start to become a problem if the stacks need to communicate with each other using versioned protocols.

Why can't you just use versioning in your external-to-the-monorepo APIs and use HEAD within the monorepo? Nothing about combining some projects into a monorepo forces you into dropping everything else we know about software release cycles.