Suggest an idea for Knip
Hello again!
Knip currently has this false positive:
await $`git -C ${directoryPath} config fetch.prune false`;With this code, Knip thinks that the "config" binary is not listed.
I fixed this bug in #1662, but Lars said that this isn't worth fixing, because it would add too much complexity to the detection algorithm, which is fine as far as I am concerned.
However, the false positives are kind of annoying - a few different ones have cropped up for me over the past 3 months since the Execa-style-template-string-analyzer-code was implemented in Knip. (I chose to showcase the Git one above since using the "-C" flag is pretty common in scripts.)
Can I propose a middle ground? What about this:
If Knip sees any variable inside of an execa template string, it just bails entirely.
That way, Knip would have have false negatives instead of false positives, which seems like a good tradeoff in this circumstance (since we intentionally don't want Knip to have the complexity to do a more robust detection).
Suggest an idea for Knip
Hello again!
Knip currently has this false positive:
With this code, Knip thinks that the "config" binary is not listed.
I fixed this bug in #1662, but Lars said that this isn't worth fixing, because it would add too much complexity to the detection algorithm, which is fine as far as I am concerned.
However, the false positives are kind of annoying - a few different ones have cropped up for me over the past 3 months since the Execa-style-template-string-analyzer-code was implemented in Knip. (I chose to showcase the Git one above since using the "-C" flag is pretty common in scripts.)
Can I propose a middle ground? What about this:
If Knip sees any variable inside of an execa template string, it just bails entirely.
That way, Knip would have have false negatives instead of false positives, which seems like a good tradeoff in this circumstance (since we intentionally don't want Knip to have the complexity to do a more robust detection).