[lijok]

> Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes.

No different to having thousands of smaller repos instead.

I personally dislike monorepos, for very niche, in-the-weeds operational reasons (as an infra person), but their ergonomics for DX cannot be understated.

[__jonas]

The 'ergonomics for DX' benefit is that you can share code across projects without having to go down the path of creating a package / library pushed to some internal registry and pulled by each project right?

Or are there any other aspects to the monorepo architecture that make it beneficial for large companies like that?

Just curious, I've never worked in such an environment myself.

[oftenwrong]

To put it in the most general terms: It provides the same value that using a VCS has for a project, but applied to the entire company.

In a standalone project, would you accept a change that is incompatible with other code in the project? For example, would you allow a colleague to change a function in a way that breaks the call sites? No, you probably would not.

The attitude within monorepo shops is that this level of rigour should be applied to the entire company. Nobody should be able to make a change anywhere if it would break anything elsewhere, or they should only be permitted to do so with intention. There are caveats to this, but that is the general idea.

[dezgeg]

In addition to what you mentioned, the ability to atomically commit to a library and all of its consumers. And for a change to a library run the tests of all of its consumers as well.

[bastawhiz]

Every host running a particular commit is running the code you think it is. No submodules or internal packages. If you updated the Button component in the design system, when your commit is deployed, every service that gets deployed has the new button now.

[aylmao]

I'd say there's 4 main advantages, summarizing what other comments are saying but also from my own experience:

- atomic PRs. All changes for a migration/feature living in one spot makes development much easier, especially when dealing with api changes and migrations

- single history. This is useful when debugging. A commit can more easily encapsulate the state of "the whole system" as opposed to a single part of it. This makes reverting, if necessary, easier

- environment consistency. updating the linting tool, formatting tool, UI library, etc is never a priority, so there's always drift, where an old repo gets stuck with old tools, dependencies and an old environment

- not shipping your org chart is easier when everyone can see and work work on the whole codebase, as easily as possible.

[triceratops]

Dependency versioning is much smoother.

Example: Service A requires version 1.1 of libFoo and libFoo 1.1 requires version 0.1 of libBar. But Service A also directly uses libBar version 0.2. Now you have a conflict.

If libFoo and libBar are internal code stored in a monorepo they're automatically version-compatible because there is only one version of both.

[fragmede]

how do you coordinate deploying a change that requires six different repos to be deployed to six different systems at the exact same time? with a mono repo, you're still deploying to six systems, but at least there's only one commit sha to keep track of.

[chrisweekly]

understated -> overstated