Is it possible to exclude results that are used within the same file?

[mildfuzz]

I have a lot of what I would consider to be false positives. A method is not being used as in import anywhere, but it being used within the same file. Is there a way to filter these out?

[nadeesha]

Thanks for the issue @mildfuzz. Although you might have a legitimate reason to export something that's not being imported elsewhere, the objective of this package is to find unused imports. If you feel like this is a worthwhile addition, I'm keen to hear your reasons.

[emlai]

+1. I think most users (including me) want to use ts-prune to find dead code. Exported entities used within the same file are not dead code, so we don't care about those cases.

In my opinion, detecting redundant usages of the export keyword doesn't add much value because those cases rarely indicate bugs (in my experience). It just means we need to manually remove the export keyword, which is slightly annoying if we don't care about them. An automatic fix mode as outlined in #23 would make it less of a problem though.

[nadeesha]

I'm more than happy to find a way to incorporate this feature if there's enough interest.

[nadeesha]

Since I'm not sure we have a viable use-case that might benefit from implementing this, I'm closing it for now.

[thehappycoder]

I'd like this feature. It's a shame this issue got closed.

[JustFly1984]

just remove export, if it is not imported anywhere.

[nadeesha]

I'd second what @JustFly1984 said. If you're not using it anywhere, I'm not sure why the export keyword should be used.

[mildfuzz]

Just like functions and variables stop being used. They get superseded. The export was useful, now it is not. Pretty common on large codebases in my experience.

…

On Sat, 25 Jan 2020, 23:14 Nadeesha Cabral, ***@***.***> wrote: I'd second what @JustFly1984 <https://github.com/JustFly1984> said. If you're not using it anywhere, I'm not sure why the export keyword should be used. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38?email_source=notifications&email_token=AABQAYMB33G2SEH4UVY6GGTQ7TBUBA5CNFSM4IFECROKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5HUUA#issuecomment-578452048>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQAYMKIAICZ4HYOJFVDCTQ7TBUBANCNFSM4IFECROA> .

[emlai]

In a large enough codebase, there can be hundreds or thousands of unnecessary exports. Going through all of them manually (due to lack of automatic fixing, #23) to check which ones can safely be removed is not always viable.

[danvk]

@nadeesha is there an alternative tool you'd recommend for finding unused code (rather than unused exports)?

[nadeesha]

@danvk Unfortunately not. That seems to be a much bigger problem :)

[nadeesha]

@mildfuzz @emlai I want to bring closure to this issue since it seems I might have closed it a bit prematurely.

The goal of this package is to find unused exports. If the export is used within the same file, there's no reason to export it, IMHO. But I can see that it could be useful to ignore these exports. But on the flip side, someone using this package to find unused exports might expect to find the unnecessary exports as well. For that person, this behaviour change would mean they no longer can find a properly unused export.

The second (unrelated) feature request here is automatic fixing as requested by #23. It's a big enough undertaking and goes against the goal of this package to not modify the source repository in any way. The reason why this is a goal is that due to the limitation of the static analysis, it's impossible to be 100% confident that an import is in-fact, unused. Faulty logic in this package, faulty logic in a dependency, Typescript introducing new syntax would all spell disastrous outcomes for someone who doesn't use a version control properly. Therefore, going by the "first do no harm" principle, I'm not going to attempt it until Typescript supports proper static analysis.

[danvk]

But I can see that it could be useful to ignore these exports. But on the flip side, someone using this package to find unused exports might expect to find the unnecessary exports as well. For that person, this behaviour change would mean they no longer can find a properly unused export.

@nadeesha are flags against your design goals for this tool? That's a fine choice if they are. But this seems like the sort of dilemma that could be resolved by one.

[github-actions]

🎉 This issue has been resolved in version 0.7.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀