While certainly interesting, the article leaves out the juicy bits monorepos and their workflows offer:
- library developers can easily see the impact their changes will have on their consumers
- library changes that introduce regressions in their consumers can be caught pre-merge given good test coverage
- dependency version updates between packages cause less mayhem because they are performed atomically and only merged when green
At the same time, many drawbacks are also left out:
- the incentive to have long living branches for stability reasons can negate most benefits mentioned above
- build times for
compiled languages can become problematic even for moderately sized organizations (I’m looking at you, C++)
- in my experience, you pretty much need a dedicated dev team working on workflow tooling because ready solutions are fragmented and hard to integrate (code review, merge bots, CI/CD, ...)
- library developers can easily see the impact their changes will have on their consumers
- library changes that introduce regressions in their consumers can be caught pre-merge given good test coverage
- dependency version updates between packages cause less mayhem because they are performed atomically and only merged when green
At the same time, many drawbacks are also left out:
- the incentive to have long living branches for stability reasons can negate most benefits mentioned above
- build times for compiled languages can become problematic even for moderately sized organizations (I’m looking at you, C++)
- in my experience, you pretty much need a dedicated dev team working on workflow tooling because ready solutions are fragmented and hard to integrate (code review, merge bots, CI/CD, ...)