4 ms·

No you use automated systems to do the change. https://mobile.twitter.com/obeattie/status/1080496955753750533?lang=en https://mobile.twitter.com/obeattie/statu

• spankalee 4y ago
  Even so, the cost is often outrageously high. No to mention that if you're the first team to import a third_party library, you own it and other teams can add arbitrary cost to you updating it. You have to be very aggressive with visibility and SLAs to work around this.
  • admax88qqq 4y ago
    You're basically just describing all the pain with pulling in a dependency regardless of monorepo or not. If the third party dependency does not add enough value to justify the cost then don't add it.
    • 8note 4y ago
      With multirepo setups, you don't necessarily need to update the package for all code at all. Instead, some newer package completely replaces an old one, with no relation to the old dependency package, or with a dependency on some future one, and both can run at the same time while turning the old one off
    • spion 4y ago
      In a multi-repo setup you can upgrade gradually though, tackling the services that need the upgrade the most first. Can you do that in a monorepo setup?
      • onion2k 4y ago
        In a multi-repo setup you can upgrade gradually.. This also means services can be left to rot for years because they don't need to be upgraded, while all the infrastructure changes around them, which is a giant pain when you do eventually need to change something. If you have a multi repo architecture you absolutely need both clear ownership of everything and well planned maintenance.
      • ec109685 4y ago
        The total pain is the same though.