Lazy imports not accessible when accessed by key

[jquense]

https://stackblitz.com/edit/github-yu5k5m?file=index.ts

Here is a trimmed down helper we use all the time demostrating the failure case. We have a more complicated one that is type safe, but is curried e.g. lazyImporter(() => import('./Foo')).getComponent('Bar'). TBH I don't really expect knip to see these, but I would love to be able to tell knip that these cases are ok via a plugin or something. Annotating the hundred+ components with knip ignore isn't really feasible and there isn't a way to determine these via a glob

[webpro]

The rule of thumb: if "Find All References" for the Foo export only returns itself in your IDE, Knip won't be able to find other refs either.

Knip covers more when using the --include-libs flag: https://knip.dev/guides/handling-issues#external-libraries

Not sure it's because this is a demo, but Component is typed any here?

Could you be more specific in how Knip could help here? E.g how to ignore such seemingly non-deterministic cases?

[AndreaPontrandolfo]

We are also facing the same issue.
The problem with React.lazy is that it doesn't allow you make lazy components that are exported with "named exports". We use ONLY named exports in our codebase, because default exports are generally bad.
So we created an util lazyImport that let use use lazy with named exports.
Of course Knip cannot see these and thus reports come components as unused, even though they are used with this special lazy import. I'm not sure how Knip could help us here, just wanted to report that this is a pain point for us too.

[webpro]

@AndreaPontrandolfo Does "Find all references" on the exported component find usages?

Knip finds this the examples of https://knip.dev/guides/handling-issues#external-libraries

But not the pattern from the OP:

const Component = lazyImport(() => import('./Foo'), 'Foo');

Would be good to find the "boundaries" here and document it better. And, indeed, ways to more easily ignore stuff and while still getting valuable reporting from Knip.

[AndreaPontrandolfo]

Does "Find all references" on the exported component find usages?

Actually yes.
I used "find all references" on my SimilarProductsSlider component, and it found the 2 usages where we import it like this:

const { SimilarProductsSlider } = lazyImport(
  () => import('@components/SimilarProductsSlider/SimilarProductsSlider'),
  'SimilarProductsSlider',
)

[webpro]

Interesting. Assuming you've tried --include-libs, this might be a bug or solvable in Knip. If you could create minimal repro I might be able to fix it.

[AndreaPontrandolfo]

@webpro oh sorry i wasn't clear, that was WITHOUT --include-libs. Using --include-libs it actually works (it doesn't report those components as unused).
Maybe the documentation around --include-libs should be expanded with this edgecase, or maybe it could beneficial to most people if it was enabled by default (and thus, opt-out).

[webpro]

It's not enabled by default, because what's required for this makes Knip pretty slow especially in larger projects. Not sure how to "auto opt-in", but better docs/discoverability would help for sure. Or some kind of "aggregate flag" to group related flags for easier opt-in. Thanks for the input.

[jquense]

Not sure it's because this is a demo, but Component is typed any here?

that would be b/c of the demo i think, it's correctly typed in normal repos

Could you be more specific in how Knip could help here? E.g how to ignore such seemingly non-deterministic cases?

I'd like to tell Knip that these are usages, ideally with my own plugin. FWIW these cases aren't non-deterministic, they are strictly and correctly typed, but defeat the tool

[webpro]

I'd like to tell Knip that these are usages, ideally with my own plugin. FWIW these cases aren't non-deterministic, they are strictly and correctly typed, but defeat the tool

there isn't a way to determine these via a glob

Sorry, still not sure how to deal with this. At this point I also don't really see how plugins could help here if they can't be determined through glob pattern(s).

The repro should be minimal yet complete/functional (at least from a TS/compiler perspective). In general, the --include-libs flag should behave as expected if TypeScript "Find all references" finds refs (other than itself).