[malkia]

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)

[gmueckl]

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.

[yorwba]

Hence why Google has Sensenmann to reap dead code: https://testing.googleblog.com/2023/04/sensenmann-code-delet...

[nullpoint420]

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.

[malkia]

Holy fuck, this is great! Thank you!

[skybrian]

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.