[tmerr]

> 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.

[JustLurking2022]

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.

[tored]

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.

[tmerr]

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.

[jvolkman]

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.