loadable-components with resolveComponent

[alexeyr-ci]

I am not sure if it should be considered a feature request or a bug (or a plugin request, for that matter).

In this loadable-components example if we remove LoadableOrange

// components.js
export const Apple = () => 'Apple!'
export const Orange = () => 'Orange!'

// loadable.js
const LoadableApple = loadable(() => import('./components'), {
  resolveComponent: (components) => components.Apple,
})

Knip will mark Apple and Orange as unused, but Apple is actually used (and Orange is not).

[alexeyr-ci]

On further thought, probably a plugin request. Should I close this and post to #483?

[webpro]

Eventually this is based on a regular import() call, would be a core feature. Probably not a candidate for a plugin, since it's dots that'll have to be connected during AST traversal.

By the way, the fact that Knip no longer detects this is a result of the v4 refactoring. In v3 this might work as expected.

Sooner or later I hope to find the time and re-implement some of findReferences within files myself, which will fix this issue.

[alexeyr-ci]

Thanks!

[alexeyr-ci]

In v3 this might work as expected.

It does. Even more, v3 detects some unused exports v5 doesn't on our project. So I'm switching to it for now (though I didn't check if there are true positives which v5 detects and v3 doesn't; probably should do that before merging).

[alexeyr-ci]

v3 detects some unused exports v5 doesn't on our project

If you don't already know cases like that, I'll try to minimize, but not sure it'll work; this is a large project and one I can't share if I can't minimize.

[webpro]

The disadvantage of v3 is that it does not have the improved handling of namespace related cases that v5 has (https://knip.dev/blog/knip-v5). I had to make the sacrifice in order to allow this and future improvements and keep it fast.

Feel free to set up cases you'd like to see covered, but no worries this point, you can also submit bug reports when it's (pre) released.

[alexeyr-ci]

Is there a way to see why v5 thinks a particular export is used (when v3 correctly detects it isn't)?

[webpro]

Try knip --trace

[shi-finnn-sportsbet]

+1 would love reimplementation of this in v5 (or v6)
I'm digging the performance increase from last I tried rolling out Knip to my project with v3, but not detecting usage of loadable components is a dealbreaker.

[webpro]

The challenge in this example case is that it requires the types of loadable to understand resolveComponent is a function with the exported object as first argument, etc. Not trivial :)

Just saying, dynamic imports in general should be handled fine by Knip, see these fixtures for examples:

• https://github.com/webpro/knip/blob/main/packages/knip/fixtures/imports/index.ts
• https://github.com/webpro/knip/blob/main/packages/knip/fixtures/module-resolution-tsconfig-paths/index.ts
• https://github.com/webpro/knip/blob/main/packages/knip/fixtures/plugins/vue-webpack/parent.vue

[coryhouse]

Hi @webpro - Loving Knip!

I believe I've found another example of this issue: React Router lazy imports:

const routes = [
  {
    path: "operations",
    // This dynamic import isn't found, so Knip reports this file as unused.
    lazy: () => import("../pages/ServiceCentersHandler"),
  }
]

Any suggestions?

[webpro]

What's the issue/output? This usage of import("../pages/ServiceCentersHandler") tells me the default export is used?

[coryhouse]

The output from knip with this pattern:

Analyzing workspace ....
Unused exports (50)
loader     function  src/pages/ServiceCentersHandler.tsx:13:17                                           
Component  function  src/pages/ServiceCentersHandler.tsx:20:17                                           
Component  unknown   src/pages/dispatch/Dispatch.tsx:3:14                                                
Component  unknown   src/pages/inbound/InboundLayout.tsx:23:14  

Each component that's lazy loaded this way shows as an unused export.

[webpro]

I see, that seems to be a different issue, quite React Router specific? Feel free to open a new issue for this, ideally with a minimal reproduction.

[coryhouse]

I see, that seems to be a different issue, quite React Router specific? Feel free to open a new issue for this, ideally with a minimal reproduction.

Thanks Lars! I just opened #556.

[webpro]

🚀 This issue has been resolved in v5.3.0. See Release 5.3.0 for release notes.

[webpro]

Please see https://knip.dev/guides/handling-issues#external-libs

The case of @coryhouse is still not resolved unfortunately. I think it's an issue with either TypeScript or the types of the external lib. Rule of thumb: if "Find references" in the IDE (e.g. VS Code) does not find references, Knip will likely do the same.