I could easily imagine someone introducing a dependency because it's needed for something, then a few months later someone refactoring to remove the code that u

I could easily imagine someone introducing a dependency because it's needed for something, then a few months later someone refactoring to remove the code that used it but not being aware that the dependency wasn't used anywhere else. Repeat this pattern a bunch, and the number of unused dependencies will start climbing. Keep in mind that the more dependencies you have, the less obvious one specific unused dependency in the config files will be (in addition to it likely being easier to introduce yet another one; it's a lot harder to object to dependency N + 1 when you didn't object to the N beforehand). Without changing the policy around dependencies themselves for a project (which presumably would be an uphill battle for anyone feeling strongly enough about this), the only way to avoid this scenario from happening without tooling would be for people to manually verify that a dependency is still used any time they remove a usage of it. Asking the person who introduces the dependency to keep track of every time someone else introduces another usage of it to the codebase would be burdensome even if you could assume that they wouldn't ever switch jobs/stop contributing to the open source project/take vacations when code is merged in their absence, and realistically I doubt that asking people to notice whenever they remove a use of a dependency and manually verify that the dependency is still used elsewhere would be particularly effective. I don't think there's any way to make this obvious in the absence of tooling, which unfortunately isn't super common in my experience even in projects that make ample use of linting other static checks in CI. I don't totally agree with the takes that this is from devs not caring about their projects or otherwise phoning it in. Often the projects I've seen struggle with things like this (and even things that are a lot more worrisome than this, like missing or flat-out wrong documentation around stuff like testing locally due to the team relying on unwritten shared knowledge of process) have developers who care deeply about what they're doing, but are stressed, burned-out, and desperately trying to tread water to avoid drowning in the sea of things they'd like to do to improve things. That's not to say that every situation like this is blameless, but unless my experience is greatly out of the ordinary, I'd think that quite a lot of us have been in or at least seen situations like this enough that we should have enough empathy not to jump to conclusions about the state of a project being a direct reflection of how much the devs care. (To be clear, I don't think this is what the parent comment I'm replying to is saying, but it does seem like overall there's a bit of a sentiment similar to this in the thread as a whole, so it feels worth calling out).