(no title)
vasvir | 5 months ago
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.
malkia|5 months ago
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)
gmueckl|5 months ago
skybrian|5 months ago