• Ephera@lemmy.ml
    link
    fedilink
    English
    arrow-up
    8
    ·
    4 hours ago

    The thing to me is always that, yeah, you need a huge commit for a breaking change in an internal library inside a monorepo, but you will still need to do the same work in a polyrepo eventually, too.

    Especially since “eventually” really means “ASAP” here. Without going through the breaking change, you can’t benefit from non-breaking changes either and the complexity of your codebase increases the longer you defer the upgrade, because different parts of your application have different behavior then. So, even in a polyrepo, you ideally upgrade all library consumers right away, like you’re forced to in a monorepo.

    • toebert@piefed.social
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 hours ago

      This is true but there is a matter of being able to split up work into multiple pieces easily and prioritise between services. E.g. the piece of legacy service that nobody likes to touch, has no tests and is used for 2% of traffic can take its’ time getting sorted out without blocking all the other services moving on.

      You still have to do it and it should be ASAP, but there are more options on how to manage it.