Hacker News Reader

> A well done monorepo is a huge force multiplier on a large organization

How so?

I work at a company which uses a monorepo, and I haven't seen any upside to it yet. We have a tools team that's invested a vast amount of work in it. Still seems strictly worse than a 'normal' polyrepo setup. I haven't understood why so many people are so enthusiastic about it.

View on HN

Do you do any cross workspace/repo work, or are you mostly constrained to a single namespace?

Not op but I do cross repo work, but it's rightfully separate PRs as its separate services, separate contracts and separate deployments. Pretending a monorepo cross service PRs are contiguous is a recipe for deployment race conditions

Is it one or the other? You either need to keep everything in separate PRs or you need to pretend that services are contiguous where deployment order doesn't matter?

1. No submodules. They suck. They don't work with worktrees. They're a pain to work with.

2. Cross-project changes become trivial instead of nightmarish.

3. Testing becomes tractable. Make a change in a submodule? Good luck testing that it doesn't break any of the other repos that depend on it. You essentially turn its API into a fully public API, which introduces a ton of extra work (if you do it right, which nobody does).

Reply on news.ycombinator.com