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

171–180 of 402 posts

Re: Monorepos: Please don’t

#171

Post by nindalf »

kiallmacinnes wrote: post #164
rossjudson wrote: post #148

Hilariously misguided. Pretty funny to read that the things I do every day are impossible. Monorepo and tight coupling are orthogonal issues. Limits on coupling come from the build system, not from the source repository. Yes, you should assume there is a sophisticated "VFS". What is this "checkout" you speak of? I have no time for that. I am too busy grepping the entire code base, which is apparently not possible. If…

> then why on earth would google invest enormous effort constructing an entire ecosystem around a monorepo? Choices: 1) Google is dumb. 2) Mono and poly are not identical. I think, once you've chosen a path of mono or poly, you have quite a challenge ahead of you to migrate to the other. At that point, the tradeoffs arent based purely on the technical benefits - and "invest in monorepo tooling" may become a perfectly…

This makes sense to me. If you're considering a monorepo with millions of lines of code used concurrently by thousands of developers, it's absolutely possible. You just need a handful of developers working on the infra to make it happen.

I do agree with GP though. I wish the author hadn't decided the things I do everyday are impossible.

Re: Monorepos: Please don’t

#172

Post by daemin »

If you spend your time maintaining and improving a low level library then having a monorepo is much better than having a polyrepo. Primarily because as you make changes to the library you can update everyone else's code that uses it rather than having to wait on them to do so. This reduces the need to maintain older versions of these libraries and applications.

Additionally you can submit the single change in one go which updates everyone and it is much cleaner than having to find out and know all of the repos that could use your library and manually submit to each one of them, probably breaking some for a time in the process.

Re: Monorepos: Please don’t

#173

Post by jon-wood »

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 very much possible to make changes to internal libraries used all over the place, but it does require versioning to be something that people think about, and a mechanism by which those libraries aren't just pulled from source control to depend on them. Once you've got some sort of dependency management such as an internal gem/npm/whatever source you can treat those internal dependencies the same as you'd treat external ones, instead of having to somehow coordinate a release of absolutely everything in one go.

Re: Monorepos: Please don’t

#174

Post by oblio »

nindalf wrote: post #171
kiallmacinnes wrote: post #164

Earlier quoted context omitted.

> then why on earth would google invest enormous effort constructing an entire ecosystem around a monorepo? Choices: 1) Google is dumb. 2) Mono and poly are not identical. I think, once you've chosen a path of mono or poly, you have quite a challenge ahead of you to migrate to the other. At that point, the tradeoffs arent based purely on the technical benefits - and "invest in monorepo tooling" may become a perfectly…

This makes sense to me. If you're considering a monorepo with millions of lines of code used concurrently by thousands of developers, it's absolutely possible. You just need a handful of developers working on the infra to make it happen. I do agree with GP though. I wish the author hadn't decided the things I do everyday are impossible.

> You just need a handful of developers working on the infra to make it happen.

With thousands of developers banging on the code base, it's going to be more than "a handful of developers". It's going to be at least a few "handfuls" of developers full time plus probably many, many other full time equivalents spread out throughout the whole user base (testing, supporting other users, etc.).

Re: Monorepos: Please don’t

#175

Post by inertiatic »

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…

My current team managed to break a single "component" out into a separate repository. Then that repository broke into two, then those broke into other repositories, until we've eventually have around 10 or so different repositories that we work on every day.

An average change touches 4 of them, and touching one of them triggers on average releases on 2 or 3 of them. Even building these locally is super tedious, because we don't have any automation in place (not formally plan to) for chain building these locally.

This is a nightmare scenario for myself. A simple change can require 4 pull requests and reviews, half a day to test and a couple hours to release.

Yet my team keeps identifying small pieces that can be conceptually separated from the rest of the functionality, even if they are heavily coupled, and makes new repos for these!

Re: Monorepos: Please don’t

#176

Post by daemin »

tome wrote: post #152
Xylakant wrote: post #125

Earlier quoted context omitted.

adding raw versions of binary assets (designs, video, ...) can quickly lift a repo beyond a TB. Now, you could say "don't do that", but there's valid use cases where you'd want to track all binary assets as part of the development cycle.

Ouch, well, yes that is a very good situation in which not to take the "mono" part of "monorepo" too seriously.

You can do that with content, you just partition the workspace/view of the monorepo to what each person needs rather than checking the entire thing out git style.

Re: Monorepos: Please don’t

#177

Post by ashelmire »

rossjudson wrote: post #148

Hilariously misguided. Pretty funny to read that the things I do every day are impossible. Monorepo and tight coupling are orthogonal issues. Limits on coupling come from the build system, not from the source repository. Yes, you should assume there is a sophisticated "VFS". What is this "checkout" you speak of? I have no time for that. I am too busy grepping the entire code base, which is apparently not possible. If…

“why on earth would google invest enormous effort constructing an entire ecosystem around a monorepo?”

Didn’t google have a monorepo before git was created? And was created by academics? Legacy and momentum have a strong influence on the future. Hasn’t google also built a lot of tools for the monorepo and dedicates employees to it? That’s exactly the issue this article is about.

From an external perspective, the speed and scale of product rollouts from the bigger tech companies is very slow. I don’t know if the tooling has much to do with it, but I suspect it might. I’ve heard some horror stories (some from here) about how it takes months to get small changes into production.

Re: Monorepos: Please don’t

#178

Post by lmilcin »

"Yeah, well, that's just, like, your opinion, man"

Monorepos are one way of solving some of the problems each organization has. Monorepos require discipline in solving those problems and if the organization is not willing to get there all the way or if it takes too much time then it's just pain and suffering for everybody.

I suspect the author works for one of those organizations that wanted to be hip but did not actually understand what it entails. Maybe faking agile and devops sort of works for you (works as in "it's difficult to pinpoint where the problem is") but faking monorepos certainly does not.

Re: Monorepos: Please don’t

#179

Post by tigershark »

Vinnl wrote: post #162
tigershark wrote: post #141

Earlier quoted context omitted.

Not always. It makes absolutely sense to have a repository for the gui and one for the server. When writing a new feature you usually write some gui code and some server code and create different pull requests. I think monorepos are seriously wrong and I completely agree with this article.

Well... Why does that make sense? I have a repository containing both the GUI and the server, and sometimes I have to make changes to both. Locating those related changes together in the same commit and/or PR makes a lot of sense to me: the changes depend on each other, and thus should be reviewed together. What's the advantage of splitting them up?

Because obviously the changes that you make in the gui are completely isolated from the changes you make on the server. When you are working on the gui the server code is just noise and vice versa. And it gets even worse when you use two different languages for the gui and the server.

Re: Monorepos: Please don’t

#180

Post by tigershark »

fnord123 wrote: post #169
tigershark wrote: post #141

Earlier quoted context omitted.

Not always. It makes absolutely sense to have a repository for the gui and one for the server. When writing a new feature you usually write some gui code and some server code and create different pull requests. I think monorepos are seriously wrong and I completely agree with this article.

>It makes absolutely sense to have a repository for the gui and one for the server. Not really. You can have a single repo with top level directories tigershark-gui and tigershark-server.

What is the point instead of having them in two separate repos?
Post reply on HN