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