Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monorepo: please do

medium.com

Post reply on HN
Print view View original

31–40 of 166 posts

Re: Monorepo: please do

#31

Post by Benjammer »

shados wrote: post #18
mmmeff wrote: post #15

Thank you so much for writing this. As someone who’s worked in the best and worst of these two words, the productivity gains are absolutely insane and the limitations, as stated by the author, are no more painful than limitations of federated/polyrepo code. Fighting back against monorepo design is dangerous - embrace experimentation.

> Fighting back against monorepo design is dangerous What's dangerous about it? Monorepos have a lot of benefits, and should absolutely be considered. Maybe even by most. But right now in the community it's almost pushed as the "only true way with all benefits and no drawbacks", and that's absolutely not true. To the point the knowledge of why and how to poly repo is already starting to get lost. That's dangerous.

The real danger here is anyone talking about any system architectures or tooling as "dangerous" (or "not dangerous") absent any other context...

What do you even mean by "dangerous"? To a business? To your health?

What is the deal with people trying to make these sorts of global assertions in a vacuum about what's "good" and "bad"? This doesn't make any engineering sense in any way to me. You have a problem and you figure out the best way for your business to solve that problem given some bounded resources. Nothing in the basic problem solving process (scientific method?) necessitates all the arbitrary "should" axioms. Why don't people just analyze their specific situation and figure out a solution?

It's like people arguing vehemently about the optimal design that every company "should" be using for all windshields for all personal vehicles on the road, without even remotely discussing various vehicle body shapes and sizes.

Re: Monorepo: please do

#32

Post by woolvalley »

My org went from polyrepo 10 commit semver dependency hell when updating an internal API to monorepo and it saves a lot of time. Unmigrated semver breaking changes are a form of technical debt, and it takes a lot more total man hours to do the 'proper' one by one many commit poly repo migration than the other way around.

If we had the tooling to do multirepo atomic commits and reviews then maybe we would of stuck with polyrepos, but it doesn't really exist out in the wild, so monorepo it was.

Re: Monorepo: please do

#33

Post by pvorb »

nkozyra wrote: post #8
slobotron wrote: post #5

Earlier quoted context omitted.

Chances are you will end up downloading a lot of dependencies anyways, why not have git deliver it all?

Huh? You'd download dependencies for the repos you need, not the code and dependencies for the entire company. It could be several orders of magnitude larger and with a larger organization could be a lot of unnecessary code that any given Dev may never touch.

But imagine the increased productivity of your devs if they only had to check out a single repo. Anyone has the same organization of projects on their machine. All tools are in one place...

Re: Monorepo: please do

#34

Post by hinkley »

sharpercoder wrote: post #2

In my experience, this discussion gets convoluted by confusing modularity with monorepo . They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo. Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.

First monorepo I worked on, we used separate compilation units for each 'module'. We paid a tax on build time but it added a bit of friction to adding new cross-module dependencies willy nilly.

I don't know how you maintain that arm's length separation if you don't have compilation units in your language of choice, and that may contribute to some of the muddiness in this kind of discussion. "It depends."

Re: Monorepo: please do

#35

Post by woolvalley »

totallysnowman wrote: post #19

I think that the reason of the argument is that both authors understand the definition of "large repository" very differently. With 100 engineers a monorepo might seem a good idea. With 500 it becomes nearly impossible to do anything involving a build. Some isolation is needed. Also from my experience many engineers just don't give a shit about architecture. They create entangled mess, that kind of works for the cust…

Why does the build not work at 500 engineers? Just because there are 5 apps / services and their 25 libraries doesn't mean you have build the 4 other apps when doing development just because you did a git pull. Libraries would still need to build their dependants in a CI system with poly or mono repos.

Re: Monorepo: please do

#36

Post by rhacker »

benmarten wrote: post #4
sharpercoder wrote: post #2

In my experience, this discussion gets convoluted by confusing modularity with monorepo . They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo. Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.

It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?

It's not for everyone, but damn, why is there a TERABYTE of code? Just curious - assets? checking in binaries?

Re: Monorepo: please do

#37

Post by hinkley »

mwkaufma wrote: post #25
benmarten wrote: post #4

Earlier quoted context omitted.

It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?

We have a perforce monorepo with ~80gb total payload for the whole thing, but everyone uses streams to filter it, so that's not a problem.

I think there's a false dichotomy here.

In the post yesterday one of the arguments was that if nobody checks out all of the code then what's the value of having the code all in one place?

Last monorepo I worked on, individual contributors checked out just the tree they were working on (we had a suite of applications with several shared modules). We made it simple and straightforward for them to get what they wanted and ignore people whose work didn't impact them.

But the senior people, who were better with architecture and version control trivia, checked out the entire thing. They would steward any cross-cutting changes that needed to be done, and make sure any callers to shared libraries were updated in the face of breaking changes. They were also backstopped by the build plans, (some of) which also checked out the entire thing.

Re: Monorepo: please do

#39

Post by tracker1 »

erulabs wrote: post #17
twblalock wrote: post #9

Earlier quoted context omitted.

If I only need to check out one of the smaller repos then I've gained quite a lot in terms of download speed, storage size, etc. Git LFS adds a lot of complexity I'd rather avoid.

Sure but then you only have some small portion of the total infrastructure, which adds its own layer of complexity for the people reviewing your changes :P It's all trade offs, is all I'm saying - I honestly still can't decide between the two, although for all companies sub 20 people, I'd for sure stick with a single repo.

If I'm working on Application X, wtf do I care about infrastructure code? Or for that matter, as a specific... if someone is working on Google Maps, should they care about the codebase for Google Inbox for Android?

Re: Monorepo: please do

#40

Post by thurn »

totallysnowman wrote: post #19

I think that the reason of the argument is that both authors understand the definition of "large repository" very differently. With 100 engineers a monorepo might seem a good idea. With 500 it becomes nearly impossible to do anything involving a build. Some isolation is needed. Also from my experience many engineers just don't give a shit about architecture. They create entangled mess, that kind of works for the cust…

the fact that essentially 100% of big tech companies use monorepos seems like evidence that it is at least possible to do it in a scalable way...
Post reply on HN