This is great in theory, but it requires _a lot_ of discipline and responsibility around dependency management from the developers.
What ends up happening in practice is that all these seemingly independent components have very strict—and sometimes even unspecified—dependencies between each other.
People create "base" packages that all other packages have a strict or loose dependency on, so when that package changes, it's a guessing game if it introduced breaking changes downstream.
With a monorepo, these dependencies are tracked and always visible, and integration testing between all dependent components becomes much easier.
It's very unlikely that you'll find truly decoupled code bases within an organization. It goes against the point of grouping people to work on a common goal to begin with.
> This is great in theory, but it requires _a lot_ of discipline and responsibility around dependency management from the developers.
Why? Again, the point is eventual consistency. If I make a breaking change, apps/services that are ready to migrate do so. The ones that aren't keep using the old version. Eventually, everyone's on the same page. The whole point is that it requires a lot less discipline.
What ends up happening in practice is that all these seemingly independent components have very strict—and sometimes even unspecified—dependencies between each other.
People create "base" packages that all other packages have a strict or loose dependency on, so when that package changes, it's a guessing game if it introduced breaking changes downstream.
With a monorepo, these dependencies are tracked and always visible, and integration testing between all dependent components becomes much easier.
It's very unlikely that you'll find truly decoupled code bases within an organization. It goes against the point of grouping people to work on a common goal to begin with.