Yes, it's nice when you can update arbitrarily distant files in a single commit. But when an API is popular enough to be used by dozens of independent projects, this is no longer practical. Even in a monorepo, you'll still need to break it up, adding the new API, gradually migrating the usages, and then deleting the old API.
Yes,
Also the other problem of a big monorepo is that nothing ever dies. Let's say you have a library and there are 1000 client programs or other libraries of your API. Some of them are pretty popular and some of them are fringe.
However when you are changing the API they all have the same weight. You have to fix them all. In the non monorepo case the fringe clients will eventually die or their maintainer will invest on them and update them. It's like capitalism vs communism with central planning and all.
If the monorepo is build and tested by single build system (bazel, buck, etc.), then it can graph leaf dependencies with no users. For example library + tests, but no one using it (granted it might be something new popping out, still in early development).
Bazel has the concept of visibility where while you are developing something in the tree, you may explicitly say who can use it (like trial version).
But the point is, if something is build, it must be tested, and coverage should catch what is build, but not tested, but also should catch what is build and tested but not really used a lot.
But why remove it, if it takes no time to build & test (?), and if it takes more time to test, it's usually on your team to start your own testing env, and not rely on the general presubmit/preflight one, and because since the last capacity planning you have only that amount of budget, you'll soon realize - do we really need this piece of code & the tests?
I mean it's not perfect, there would be always something churning using time & money, but until it's pretty big problem it won't go away automatically (yet)
Dead cose in a huge monorwpo is more costly than just build and test time. It's also noise when searching through code. One thing to realize is that deleting dead code from the tree doesn't destroy anything because it's still in the repo history and can be restored from there.
Hence why Google has Sensenmann to reap dead code: https://testing.googleblog.com/2023/04/sensenmann-code-delet...
It's common to think monorepos are a way of shipping code. IMO, they're actually a mental model or model of your code and its dependencies. It's not just tooling for tooling sake, it gives you a new view into your code and its dependencies.
Holy fuck, this is great! Thank you!
Libraries with no usages can easily be deleted. For entire apps, it’s harder to tell whether they’re still used, because that information isn’t in the repo.