Hacker News Reader

Comment by JustLurking2022 | Hacker News Reader

JustLurking2022

Having worked in companies with large monorepos and those without, I would never advise implementing one.

The complexity as a function of repo size grows at something greater than linear rate. Code becomes tightly intertwined and the dependency graph becomes unwieldy, making refactoring a difficult proposition.

Eventually, the codebase always grows to a size that makes it impractical to replicate on each developers' machine, so you start having to implement workarounds, and you realize that just keeping basic build operations working requires a substantial team to support. For the big players, they can eat the cost no problem, but it's still not money well spent and certainly not advisable for orgs without that level of resourcing.

View on HN

> Code becomes tightly intertwined and the dependency graph becomes unwieldy

One way to combat this is to use a build system with a notion of visibility, https://bazel.build/concepts/visibility

I think you might be over-extrapolating from your experience, but it's true going off the well-trodden road leads to surprises. And not that many smaller companies know the ins and outs of monorepos.

I have... as mentioned, worked in one of the large tech companies with a monorepo, and they all use fairly similar tooling.

In practice, it doesn't solve the problem because most people default to making everything public. Nominally this avoids duplicating logic, but may result in more stuff being pulled in than was really necessary. These days, when NodeJS developers discuss how bad things have gotten with dependency management, I just laugh.

How would you handle versioning in a monorepo? Just a new directory for major versions?

If we have multiple teams you can’t really refactor other teams code and sometimes you need to do breaking changes thus I imagine that some versioning must exist.

A big part is engineering culture. At Google having multiple versions of a thing is an exceptional situation. But it's also acceptable (to an extent) to refactor other peoples' code and send them PRs. If you need to make a significant change, you do it in phases that allow you to maintain compatibility until you or someone else is able to migrate usages to the new ways.

That's a great question. What I've seen is versioning de emphasized. Good unit & integration test coverage to prevent refactor breakage. And when you make a large change that affects consumers of your library, you find a way to do it incrementally. E.g. instead of changing a function's parameters, you can create a second function, migrate everyone over, then delete the old one. And of course, you would not ordinarily modify another teams code without first getting their LGTM.

Reply on news.ycombinator.com