Comment by devjab
This is cool, as a place which uses Typescript for a lot of things, including back-end services we handle it differently. Basically we have a rather strict linting process setup which will warn developers of unused code in development environments and outright refuse it for staging deployment and forward. I’m not sure we would “dare” to automatically remove it, because for the most part there is a reason it is there. Maybe it’s something that needs to be deleted, but it’s almost always something which needs to be handled in some way.
Unused imports is perhaps the one area where I would be comfortable removing unused imports. I would never personally allow a third party package into our environment for something like this. I really don’t want to be rude about it, but it’s too “trivial” to rely on an external import for. Not because your code couldn’t be better than ours, it probably will be, but because it’s an unnecessary risk.
For smaller or personal projects I think many people will rely on something like prettier to do the same.
Thanks for the input! I think there may be a misunderstanding about what this does. Existing linters work great for detecting unused code within a file but once you add `export` to it, you can’t detect unused code with linters even if it’s not referenced from any file.
You’re right that this tool may not be useful for some codebases. If your modules are more like “scripts” that include side effects, deleting modules just because it’s not referenced may break things. That should not be the case for react projects that are based on components.
In our development process, we don’t allow the changes made by this tool to be deployed automatically. Instead we make sure the changes are okay by creating a pull request and reviewing. We treat it more like an assistant that does all the cumbersome clean up work in no time.