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

11–20 of 402 posts

Re: Monorepos: Please don’t

#11

Post by im_down_w_otp »

The biggest gripe I have with modern day monorepos is that people are trying to use Git to interact with them, which doesn't make a tremendous amount of sense, and results in either an immense amount of pain and/or the creation of a bunch of tools to try to coerce Git into behaving basically like SVN.

Which of course begs the question, rather than trying to perform a bunch of unnatural acts, why not just use SVN to start with? It works extremely well with monorepo & subtree workflows.

Sure it has some warts in a few dimensions around branching, versioning, etc. compared to Git when using Git in ways aligned with how Git wants to work, but those warts are minimal in comparison to what's required to pretzel Git monorepos into scaling effectively.

Re: Monorepos: Please don’t

#13

Post by joeblau »

sterlind wrote: post #7

Could you get the best of both worlds by having a monorepo of submodules? Code would live in separate repos, but references would be declared in the monorepo. Checkins and rollbacks to the monorepo would trigger CI.

We actually did this. When I started at Uber ATG one of our devs made a submodule called `uber_monorepo` that was linked from the root of our git repo. In our repo's `.buckconfig` file we had access to everything that the mobile developers at Uber had access to by prefixing our targets with `//uber_monorepo/`

We did however run into the standard dependency resolution issue when you have any loosely coupled dependency. Updating our submodule usually required a 1-2 day effort because we were out of sync for a month or two.

Re: Monorepos: Please don’t

#14

Post by mrgriffin »

My problem with polyrepos is that often organizations end up splitting things too finely, and now I'm unable to make a single commit to introduce a feature because my changes have to live across several repositories. Which makes code review more annoying because you have to tab back and forth to see all the context. It's doubly frustrating when I'm (or my team is) the only people working on those repositories, because now it doesn't feel like it gained any advantages. I know the author addresses this, but I can't imagine projects are typically at the scale they're describing. Certainly it's not my experience.

Also I definitely miss the ability to make changes to fundamental (internal) libraries used by every project. It's too much hassle to track down all the uses of a particular function, so I end up putting that change elsewhere, which means someone else will do it a little different in their corner of the world, which utterly confuses the first person who's unlucky enough to work in both code bases (at the same time, or after moving teams).

Re: Monorepos: Please don’t

#15

Post by WorldMaker »

thehazard wrote: post #12

Better title would be "Monorepos don't fit with my particular use case."

I disagree. The thesis statement repeated several times throughout is "Monorepos don't scale in exactly the same ways that polyrepos don't scale, the tools to solve the scaling problems are the exact same except monorepos need more of them and encourage bad habits along the way."

You may disagree with that thesis, but it definitely seems to cover more than one use case.

Re: Monorepos: Please don’t

#16

Post by WorldMaker »

mrgriffin wrote: post #14

My problem with polyrepos is that often organizations end up splitting things too finely, and now I'm unable to make a single commit to introduce a feature because my changes have to live across several repositories. Which makes code review more annoying because you have to tab back and forth to see all the context. It's doubly frustrating when I'm (or my team is) the only people working on those repositories, becaus…

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 "their" file and they got an automated notice from a hidden rules engine in your CI process you didn't even realize existed.

In the polyrepo case those boundaries have to be made explicit (otherwise no one gets anything done) and those owners should be easily visible. You may not like the friction they sometimes bring to the table, but at least it won't be a surprise.

Re: Monorepos: Please don’t

#17

Post by WorldMaker »

erik_seaberg wrote: post #6
muro wrote: post #4

Earlier quoted context omitted.

Yet who unpins them or updates when a new good version is available?

There's a cost for being out of date, but there's also a cost for learning the hard way whether a new version breaks prod. Pay it down like any other tech debt. Maybe I could test literally every release version of each of my dependencies, but that isn't really my job.

Greenkeeper (and similar systems) comes to mind, too, in the polyrepo case. You can still CI with "the latest" in the polyrepo case. We have the technology to automate that. Including situations like 'let me know when the next version of my dependency that passes this test is released and send me a PR to update my pinned version when it happens'.

Re: Monorepos: Please don’t

#18

Post by lioeters »

towaway1138 wrote: post #9

My polyrepo cautionary tale: Two repos, one for fooclient, one for fooserver, talking to each other over protocol. Fooserver can do scary dangerous permanent things to company server instances, of which there are thousands. Fooserver sprouts a query syntax ("just do this for test servers A and B"), pushed to production. Fooclient sprouts code that relies on this, pushed to production. A bit later, Fooserver is rolled…

Ouch. I suppose the lesson is that a monorepo with both client and server being developed and tested together would have reduced such risk.

Re: Monorepos: Please don’t

#19

Post by WorldMaker »

superasn wrote: post #2

The biggest advantages monorepos have offered is development of tools like lerna(1) or yarn workspaces. Before that there used to be a node_modules folder with GBs of [useless] data in all my projects. Now there is just one folder on top and that's it. Also if you're developing lots of modules or plugins it makes it super to work without committing changes since they are symlinked. (1) https://lernajs.io

node_modules is an interesting worst case of package management systems.

There's some good exploratory work currently happening on making node_modules and the node package ecosystem better in general, but especially in the polyrepo case. Yarn "Plug'n'Play" is one, and Tink [1] the other.

[1] https://npm.community/t/tink-faq-a-package-unwinder-for-java...

Post reply on HN