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

Monorepos: Please don’t

medium.com

Post reply on HN
Print view View original

231–240 of 402 posts

Re: Monorepos: Please don’t

#231

Post by eadmund »

notacoward wrote: post #201
joshuamorton wrote: post #74

Earlier quoted context omitted.

Why would you need to rebase or cherrypick unless you and the other team were touching the same files?

Problem is, places that use monorepos also tend to have whole teams full of people who feel entitled to f#ck with stuff across the entire repo, often without going through the normal review or other processes for each component. Thus it's not uncommon to commit code early in the day so that you can build packages for system test, find a problem in system test, then come back later the same day to find one of those ra…

> places that use monorepos also tend to have whole teams full of people who feel entitled to f#ck with stuff across the entire repo

That's only true to the extent that the statement 'places that use multirepos also tend to be full of people who feel entitled to f#ck with stuff across the entire codebase' is.

Bad colleagues can cause damage either way. I appreciate that with a single repo, bad colleagues are at least forced to have passing tests after their changes, rather than leaving it to me to pick up the pieces.

Re: Monorepos: Please don’t

#232

Post by briantakita »

eadmund wrote: post #208
dtech wrote: post #202

Earlier quoted context omitted.

3) A monorepo with significant investment in ecosystem and tooling is a better choise than a polyrepo For other (smaller) companies, polyrepo might be the better choice because [significant investment in ecosystem and tooling] is not appealing, and the investments of Google et al. have not leaked through sufficiently into general available tools. Some headway is being made in the latter [1], so monorepo might be the…

> For other (smaller) companies, polyrepo might be the better choice because [significant investment in ecosystem and tooling] is not appealing That's not the choice, though: significant investment in tooling is a function of codebase size. In my own experience, polyrepos require more tooling, because you're not just dealing with files & directories, you're also dealing with repos (& probably PRs & issues & other stu…

Another thing is that the OP categorized "medium sized menorepos" as being too large to fit on a laptop. Maybe the companies I've worked for is limited (mainly startups & consultancies), but the entire codebase, after several years of operation, still easily fits on a single laptop.

Of course there is a threshold, however this is typically a concern of a large organization or an organization that has been producing software for a decade or more.

Re: Monorepos: Please don’t

#233

Post by thedufer »

ashelmire wrote: post #209
titanomachy wrote: post #187

Earlier quoted context omitted.

Does Google require more engineers to support their build system than they would with a polyrepo? That question is not trivial to answer, IMO.

Any is more than 0 though. In my experience (probably shared by many devs), polyrepos don’t require a team, or even a single person, dedicated to version control. It’s a minor part of the software management (usually: “mind if I create a new repo for this?” “Yes/no”). It does affect dependency management but no more than any external dependency.

A polyrepo setup at Google's scale would pretty obviously require some dev work. For example, their CI/build story would be way more complex.

Re: Monorepos: Please don’t

#235

Post by briantakita »

Mxtetris wrote: post #45
WorldMaker wrote: post #16

Earlier quoted context omitted.

It's an interesting social problem in how you manage those project / library / repository boundaries. On the flipside, though, it's been well documented that among many of the major monorepos those boundaries still exist, they just become far more opaque because no one has to track them. You find the weird gatekeepers in the dark that spring out only when you get late in your code review process because you touched "…

Can a monorepo support module- or subdirectory-level ownership controls? Or do teams using a monorepo just do without them? Partially answering my own question: SVN, recommended in a prior comment [0], supports path-based authorization [1]. But what about teams using another version control system? [0] https://news.ycombinator.com/item?id=18810313 [1] http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverc...

For my clients, I use an open source monorepo submodule inside the client's proprietary monorepo. I can maintain the organizations' software while sharing common code.

So (mono)repos are composable.

Re: Monorepos: Please don’t

#236

Post by LaGrange »

banachtarski wrote: post #230
LaGrange wrote: post #186

Earlier quoted context omitted.

3) Google is committed to a monorepo to the point migrating away from it would be unpractical. Truth is, ending up with a monorepo is _really easy_. It usually starts with something that doesn't even _feel_ like more than one project: backend code, frontend templates and some celery/whatever tasks, maybe some minor utility CLI tools. And this happens at the stage nobody wants to even _think_ about more than one git r…

I've worked with both monorepo orgs, and polyrepo orgs. I think if you have only used git as your VCS and not something like perforce, you're likely to get the wrong idea of how it works. Both CAN work, but for internal organizations with a reasonably sized team, I've come to realize that a mono repo is better. You attain "separation" by establishing different views of the code/data and at scale, the mental model of…

> I think if you have only used git as your VCS and not something like perforce

I think if you worked with Perforce, you're likely to get the wrong idea that people who dislike monorepos didn't work with Perforce. But the reality is that anyone who worked in this industry long enough did at some point end up traumatised by it, thanks.

> the mental model of what's happening is much simpler.

How does introducing the concept of "views" to the VCS model make anything simpler?

Re: Monorepos: Please don’t

#237

Post by diminoten »

rakoo wrote: post #223

So the conclusion is "monorepo or polyrepo, you'll need a lot of tooling anyway. So why use monorepos?" Very easy: because having everything in a single place is just easier to work with.

Easier because you can commit more atrocities.

Easier is not better, some things should be hard to do to dissuade you from doing them. Stop burdening your co-workers!

People in here keep saying "easy" like it's the end goal, but it's not. Correct is. Writing great software is hard, and monorepos make it even harder to do that because a monorepos encourages an "anything goes" vibe.

Re: Monorepos: Please don’t

#238

Post by briantakita »

jayd16 wrote: post #117

There's a lot wrong with this article. Most of the arguments are either not backed up or are misleading. I haven't heard anyone argue they can drop dependency management because of a monorepo. The author lists downsides of monorepos without listing the upsides and downsides of polyrepos so its really half complete. I don't think anyone who likes a monorepo is suggesting you just commit breaking changes to master and…

"... Please don't" titles also give off a condescending vibe, which usually means the author has erected strawmen, is appealing to emotion, & has not thought things through.

Re: Monorepos: Please don’t

#239

Post by notacoward »

eadmund wrote: post #231
notacoward wrote: post #201

Earlier quoted context omitted.

Problem is, places that use monorepos also tend to have whole teams full of people who feel entitled to f#ck with stuff across the entire repo, often without going through the normal review or other processes for each component. Thus it's not uncommon to commit code early in the day so that you can build packages for system test, find a problem in system test, then come back later the same day to find one of those ra…

> places that use monorepos also tend to have whole teams full of people who feel entitled to f#ck with stuff across the entire repo That's only true to the extent that the statement 'places that use multirepos also tend to be full of people who feel entitled to f#ck with stuff across the entire codebase' is. Bad colleagues can cause damage either way. I appreciate that with a single repo, bad colleagues are at least…

That hasn't been my experience. Yes, it's a culture thing rather than a technology thing, but with a monorepo the "core" or "foundation" or "developer experience" teams tend to act like they're the owners of all the code and everyone else is just visiting. With multiple repos that's reversed. Each repo has its owner, and the broad-mandate teams are at least aware of their visitor status. That cultural difference has practical consequences, which IMO favor separate repos. The busybodies and style pedants can go jump in a lava lake.

> with a single repo, bad colleagues are at least forced to have passing tests

Passing unit tests, big whoop. Maybe sometimes light functional tests. Integration/system/stress tests that have to run across an entire cluster for non-trivial time to get meaningful results and thus can't easily be kicked off from a commit hook? Not a chance. The coverage that results is no better (or even different) than what you'd get with separate repos.

Re: Monorepos: Please don’t

#240

Post by gitgud »

forkerenok wrote: post #154
bad_user wrote: post #109

Earlier quoted context omitted.

Components might need to be released “together”, but if they are worked on by different teams, it means they’ll have a different release process, as in different timeline, different priorities. First of all this is normal, because otherwise the development doesn’t scale. In such a case the monorepo starts to suck. And that’s the problem with your philosophy ... it matters less how the components connect, it matters m…

And no, you cannot split a monorepo into a polyrepo easily. Been there, done that. _The reason is that working in a monorepo versus multiple repos influences the architecture quite a lot and the monorepo leads to very unclear boundaries. I think you are conflating a monorepo (where boundaries can still be established, e.g. via a module isolation mechanism specific to the stack used) with a "monoproject"/"monomodule",…

If the projects within the monorepo are decoupled and have clear boundaries then why not have them in separate repositories?...

In my opinion monorepos make refactoring dependant projects much easier. However it is much harder to establish and enforce clear boundaries...

Post reply on HN