1. 6
  1.  

  2. 2

    This is an interesting approach, but I feel like the implementation complexity and management of the system might outweigh the benefits in the long term.

    In a monorepo, I can run the equivalent of make in the root and see what happens. With this system, I have to have something that integrates and knows about all my repos, knows how to issue pull requests, and knows how to bump versions and recompile/test to ensure that it works. On top of this, it’s a separate system that itself needs to be maintained, and maintain compatibility with all its consumers (i.e. other service repos).

    Sure, someone has to set up the build system, but its maintenance becomes a necessary part of getting your software out the door; it’s not going to fall behind or become out-of-date easily.

    Mind you, this system sounds great! I’m just not sure how feasible such an approach is without investing a very high amount of engineering resources into it.