Annotate results that are used within the same file

[danvk]

Fixes #38

With this PR, exports that are never imported but are still used within their own module are annotated as such:

$ ts-prune src/B.ts:9 - UnusedFooType src/C.ts:9 - default src/cities.ts:1 - sepehub src/cities.ts:2 - kuariob src/cities.ts:4 - femvacsah src/cities.ts:5 - sijelup src/internal-uses.ts:5 - usedInThisFile (used in module) src/internal-uses.ts:7 - thisOneIsUnused src/internal-uses.ts:9 - UsedInThisFile (used in module) src/internal-uses.ts:11 - Unused src/internal-uses.ts:13 - Row (used in module) src/internal-uses.ts:17 - UnusedProps src/dynamic/fail.ts:1 - foo src/dynamic/fail.ts:3 - bar 

If you don't consider these symbols problems, you can grep them out with:

ts-prune | grep -v 'used in module' 

If you do consider these problems, you can ignore the "(used in module") or use sed or some such to get rid of it.

[nadeesha]

I think this is a worthwhile addition. Thanks @danvk.

[nadeesha]

Would you kindly refactor this to not use _ chaining please? You're free to use the fp constructs as you wish :)

Somethings like:

const referenceCounts = countBy((idsInFile || []).map(node => node.getText())); const referencedInFile = Object.entries(referenceCounts)...

[danvk]

Sure, done, though I am curious what the objection to chaining is. It has to be countBy(x => x)(...), the iteratee seems to be required w/ lodash-fp.

[nadeesha]

You can write it alternatively as countBy(x => x, input) as well.

It's more of a preference to use the fp methods, than a hesitation to use chaining. I find the fp methods work on immutable data, have consistent interfaces, and can be chained with pipe.

[danvk]

Thanks @nadeesha. I was thinking that one way to merge this while keeping the spirit of "zero configuration" would be to add some sort of marker to the output for internally-used exports. That way you can grep them out if you're not interested.

Perhaps something like:

$ ts-prune src/internal-uses.ts:5 - usedInThisFile (exported but used in module) src/internal-uses.ts:7 - thisOneIsUnused src/internal-uses.ts:9 - UsedInThisFile (exported but used in module) src/internal-uses.ts:11 - Unused src/internal-uses.ts:17 - UnusedProps 

Or if that's too verbose, then:

$ ts-prune src/internal-uses.ts:5 - usedInThisFile * src/internal-uses.ts:7 - thisOneIsUnused src/internal-uses.ts:9 - UsedInThisFile * src/internal-uses.ts:11 - Unused src/internal-uses.ts:17 - UnusedProps 

Let me know what you think.

[danvk]

Hi @nadeesha, I've gone ahead and implemented the idea of tweaking the output to reflect whether symbols are used in their own modules:

src/B.ts:9 - UnusedFooType src/C.ts:9 - default src/cities.ts:1 - sepehub src/cities.ts:2 - kuariob src/cities.ts:4 - femvacsah src/cities.ts:5 - sijelup src/internal-uses.ts:5 - usedInThisFile (used in module) src/internal-uses.ts:7 - thisOneIsUnused src/internal-uses.ts:9 - UsedInThisFile (used in module) src/internal-uses.ts:11 - Unused src/internal-uses.ts:13 - Row (used in module) src/internal-uses.ts:17 - UnusedProps src/dynamic/fail.ts:1 - foo src/dynamic/fail.ts:3 - bar 

If you don't consider these symbols problems, you can grep them out with:

ts-prune | grep -v 'used in module' 

We can tweak the wording / formatting, of course. Let me know what you think.

[github-actions]

🎉 This PR is included in version 0.7.3 🎉

The release is available on:

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

Your semantic-release bot 📦🚀