4 ms·

Bingo. Monorepos work because tooling makes it work. Just putting all your code in one place doesn't make it a monorepo--just makes it a mess.

• gorgoiler 3y ago
  It was a mess before, but the mess wasn’t visible. Now the code is all visible to the IDE, it all compiles together, and tests together. You can see the mess and fix it. It’s possible to see enough of it to be able to change it and when you do the build stays green because you can make atomic changes. It’s less about why monorepos are good, and more about why on Earth would you split a product up over hard repo / tooling boundaries. Perhaps a Big Brain could get those boundaries right. I can’t, so when I need to move the boundary I would rather it was done by editing code inside a repo than coordinating changes between micro products. I’m obviously describing one scenario. What are the counter examples for where hard polyrepo boundaries are helpful? When your team are all IC1s?
  • jwestbury 3y ago
    > You can see the mess and fix it. The trouble is, you're often left unwinding a half-dozen layers of abstraction, and in many cases experiencing what looks like some sort of quantum code interaction, where changes in one part of the codebase seem to impact completely unrelated bits of code which now fail tests. The polyrepo + microservices approach helps enforce boundaries. It also makes rapid iteration easier with more limited tooling, because my code can no longer blow up someone else's code -- a problem which can be solved with dev toolchains, but those toolchains take a non-trivial amount of resources to support. I do agree, when you need to move boundaries, or need to refactor across multiple packages at once, a monorepo + monolith is great. (A monorepo + microservices can introduce many of the same problems as a polyrepo + microservices, though.)
    • Zanfa 3y ago
      > The trouble is, you're often left unwinding a half-dozen layers of abstraction, and in many cases experiencing what looks like some sort of quantum code interaction, where changes in one part of the codebase seem to impact completely unrelated bits of code which now fail tests. This perfectly sums up all of the microservice apps that I’ve had the pleasure of working on, with the exception of issues being caught by tests. Typically you get either silent production data corruption or a seemingly unrelated error in the UI x weeks down the line.
  • erik_seaberg 3y ago
    People seem to think Google’s monorepo is amazing, but I was often blocked from deploying anything because some team I never heard of submitted a changelist that broke the world. We should be using known-good dependencies rather than alpha testing the bleeding edge.
• tm-guimaraes 3y ago
  Bingo. At $work i see lots of projects leaving the monorepo due to that very mess. The problem is that services outside have other CI and maintenance issues that wouldn’t happen in the monorepo. But monorepo got so messy that it got unbearable. The proper solution would be to have a dev teams dedicated to tooling for it, the org has the resources, but it’s just not investing enough in that area.
  • deleted 3y ago
    [deleted]