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

301–310 of 402 posts

Re: Monorepos: Please don’t

#301

Post by skj »

gdfasfklshg4 wrote: post #255
skj wrote: post #211

Earlier quoted context omitted.

You make the endpoint first, and test it without the UI. What challenges do you foresee here?

* Changing graphql schemas. * Any non-backwards compatible change in the interface between the components. Yes this can be solved. But when working in a smaller team on proprietary software why use time solving a problem you don't need to solve? (This is from experience.)

> why use time solving a problem you don't need to solve?

Unless they're running on the same computer and deploy literally simultaneously, this is already a problem you need to solve.

Re: Monorepos: Please don’t

#303

Post by mlthoughts2018 »

zeveb wrote: post #295
mlthoughts2018 wrote: post #283

Earlier quoted context omitted.

In my experience, monorepos cause outrageous problems that have nothing to do with scale. Small or medium monorepos are equally as terrifying. It’s much more about coupling and engendering reliance on pre-existing CI constraints, pipeline constraints, etc. If you work in a monorepo set up to assume a certain model of CI and delivery, but you need to innovate a new project that requires a totally different way to appr…

Oddly enough, you could s/mono/multi in your post and that would exactly align with my own experience. I'm not kidding: everything from engendering reliance on weird homegrown tooling, CI & build pipelines to the pain of trying to break out to a different approach, to enforced bad practices, to developers (unknowingly) misleading management, to colossal failures. I've worked on teams with monorepos and teams with mul…

Everyone always says this type of response about everything though. If you like X, you’ll say, “In my experience you can /s/X/Y and all the criticisms of X are even more damning criticisms of Y!”

All I can say is I’ve had radically the opposite experience across many jobs. All the places that used monorepos had horrible cultures, constant CI / CD fire drills and inability to innovate, to such severe degrees that it caused serious business failures.

Companies with polyrepos did not have magical solutions to every problem, they just did not have to deal with whole classes of problems tied to monorepos, particularly on the side of stalled innovation and central IT dictatorships. Meanwhile, polyrepos did not introduce any serious different classes of problems that a monorepo would have solved more easily.

Re: Monorepos: Please don’t

#304

Post by mr_tristan »

Open source software workflows are very common and provide a _lot_ of tooling, e.g., Maven, bundler, npm, etc. Add semantic versioning and you have a lot of tooling that you basically get for free for polyrepo setups. With monorepos, you have to really spend a lot of time tooling, because you basically don't use the OSS tools.

There's a lot of odd arguments in this blog that are very spurious:

"If an organization wishes to create or easily consume OSS, using a polyrepo is required."

What? _Consuming_ OSS is usually not that bad. I've even imported the complete history from external repos, pretty easily. (It does suck with git but I wouldn't use git for a monorepo...) _Contributing_ to OSS is tricky, but the fact you use a polyrepos don't really help you much there either.

"Polyrepo code layout offers clear team/project/abstraction/ownership boundaries and encourages developers to think carefully about contracts."

Clear ownership boundaries has _zero_ to do with polyrepos. In fact, I'd say monorepos can be easier, since you say "everything under this directory is owned by X,Y,Z". There's no search function that's required to figure out where some other team hid their code. So many times, with polyrepos, projects are _hidden_ because they're off in some other grouping unit that you're not a member of. So you don't even know who owns what or where it came from.

In the end, I'd still strongly recommend using polyrepos because you get _a lot_ of tooling for free, and most integration issues are solved with semantic version locking and CD automation. But the arguments here are not really great.

Re: Monorepos: Please don’t

#305

Post by sangnoir »

majewsky wrote: post #210
forty wrote: post #113

Earlier quoted context omitted.

My rule of thumb is: if you need to do PRs in several repositories to do one features, you should probably merge the repositories. At work, we have code spread among a bunch of repositories, and having to link to the 2/3 related PRs in other repos is a major PITA, and even more so for the reviewers.

Just because things change in tandem, that does not mean that they're all the same thing. When I add a new function to my backend service, all frontends that consume its API also need to be adjusted. But that doesn't mean that the backend service, its command-line clients and its web GUI client should live in the same repo.

It's probably a matter of taste - but I think they should be in the same repo. I like tying test failures/regressions to a specific commit for documentation and admin purposes. Having a test fail or regression due to an 'unrelated' commit in another repo sounds like a nightmare waiting to happen when you try investigating.

I the difference of opinion is between developers who work on self-hosted "evergreen" products where the latest version is deployed, and others who work with multiple release branches with fixes/features constantly being cherry-picked.

Re: Monorepos: Please don’t

#306

Post by bjourne »

majewsky wrote: post #210
forty wrote: post #113

Earlier quoted context omitted.

My rule of thumb is: if you need to do PRs in several repositories to do one features, you should probably merge the repositories. At work, we have code spread among a bunch of repositories, and having to link to the 2/3 related PRs in other repos is a major PITA, and even more so for the reviewers.

Just because things change in tandem, that does not mean that they're all the same thing. When I add a new function to my backend service, all frontends that consume its API also need to be adjusted. But that doesn't mean that the backend service, its command-line clients and its web GUI client should live in the same repo.

Why? You are just creating more work for yourself by keeping the components in different repos. Now you need to create N commits when updating something. If your future self wants to investigate how the software has evolved there are N times as many commits to analyze.

Re: Monorepos: Please don’t

#307

Post by zeveb »

swish_bob wrote: post #260
thedufer wrote: post #233

Earlier quoted context omitted.

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.

While that may be true, I'm not convinced it is a given. Any complicated enough monorepo requires complex CI/build tools, and Bazel/Blaze exist for a reason ...

> Any complicated enough monorepo requires complex CI/build tools

Any complicated multi-repo setup requires tooling, processes, procedures, cross-repo PRs & issue tracking, &c. &c. &c.

The question is: which requires less cost in order to deliver business value? In my experience, on the teams I've been so far, the answer has been monorepos — but I don't know everything.

Re: Monorepos: Please don’t

#308

Post by jenscow »

EngineerBetter wrote: post #263
fnord123 wrote: post #244

Earlier quoted context omitted.

>Exceptions? Nah, multiple returns! Dependency management? Who needs it... Oh, wait. I thought consensus was that exceptions, like OOP, is an antipattern. I guess there's room for different opinions. :-/

Consensus could be a synonym here for 'current trends'. I see no advantage of returning error types over checked exceptions. I'm happy to be informed, though.

You obviously haven't written any win32 applications :)

Where a function may return zero, non-zero, not-ERROR_SUCCESS, INVALID_HANDLE, NULL, (there's more), to indicate an error. You then need to call GetLastError which gives you a number that you input into google to get a generic error message.

You "should" also wrap every api call in this error checking so you know where the failure began.

Re: Monorepos: Please don’t

#309

Post by mcguire »

"If an individual clone got too far behind, it took hours to catch up (for a time there was even a practice of shipping hard drives to remote employees with a recent clone to start out with). I bring this up not specifically to make fun of Twitter engineering, but to illustrate how hard this problem is."

But mostly to make fun of Twitter engineering.

Seriously, what advantages would a big bag of billions of lines of code have?

Re: Monorepos: Please don’t

#310

Post by ashelmire »

thedufer wrote: post #233
ashelmire wrote: post #209

Earlier quoted context omitted.

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.

The nice thing about polyrepo is that each repo doesn't care what the others are doing. They can use whatever tools they prefer (whatever is least work and most familiar for the team, perhaps). It might also encourage better documentation and adherence to good practices with regard to deprecation and maintenance.
Post reply on HN