3 ms·

We know how to do that. Versioning, deprecations etc. We do that with all external dependencies.

• masklinn 4y ago
  All of which adds more effort, more synchronisation, more delay, more processes, and more ceremony. > We do that with all external dependencies. Indeed. Why you’d want to also suffer that for internal dependencies when there is no reason to, I can’t fathom.
  • spion 4y ago
    I think this article clearly shows that the effort of handling a monorepo is way higher. If you have a good process for external dependencies you can apply that to internal. If you don't have a good process for external dependencies a monorepo won't help (unless you make all your dependencies internal, which is even more expensive)
    • rfoo 4y ago
      > If you have a good process for external dependencies you can apply that to internal. Yeah... but usually good process for external dependencies requires a lot of ceremony and takes maybe days to update one dependency. If the same happens to internal dependencies we will be just slower at making changes for no good reason. This is more of a cultural thing. In fact, we are creating complicated solutions to mitigate this problem, only to go full circle after a while: people implemented Service Mesh via proxy sidecars, it added more layers (than just embedding this into the RPC library), but even doing so is easier than persuading downstream project owners update their dependency in a timely manner, so it takes off. And now they are going to chase for "proxyless" due to "performance". Oh well.
      • spion 4y ago
        Why would a complex dependency update be faster in a monorepo? In my experience the biggest savings are for simple updates that happen acorss multiple repos - when the update itself is complex, the extra time to make multiple PRs is dwarfed by the actual update's complexity, and it helps if the update can be separated into several projects where the version can be bumped separately.
        • rfoo 4y ago
          A lot of things could be done in a series of "simple updates that happen across multiple repos". Different style of doing the job I guess. Also, having a rather global view of the impact of my code before actually make the change helps a lot, especially if you are working on low-ish level libraries. Technically this is not bound to monorepo, but people usually criticize the complexity introduced by having such ability for monorepo, so :)
        • sagarm 4y ago
          You don't "update" the dependency. You are always building and releasing at head with all your internal deps (external deps are still versioned of course). > the extra time to make multiple PRs is dwarfed by the actual update's complexity Writing code is never the majority of the work. All the operational stuff is more complex without forced upgrades: coordinating the dependency updates, automating integration testing, pushing clients to migrate off old thick clients, determining what version of a specific repo is deployed, running a bisect to root cause issues, etc.
  • oceanplexian 4y ago
    As a Systems Engineer / SRE you’re damn right it adds more effort and delay. And it’s not because there’s “no reason” but because when you’re operating a production service at scale you need to put in the effort to make sure dependency changes won’t cause a massive outage or lose customer data. Automated tests and CI/CD only go so far and are not a cure-all.
  • tynpeddler 4y ago
    The process for rolling out breaking API changes is the same for monorepos as it is for multi-repos since, during a deploy, multiple versions of each service will be running simultaneously. The only advantage of a mono-repo is the atomic commit across multiple services. It's definitely possible through a combination of convention and tooling to do something similar with a multi-repo, but as of yet this is a less explored paradigm.