feat(nuxt): use nuxt to resolve its own paths

[danielroe]

resolves #1255

this rewrites the nuxt plugin to use nuxt itself to resolve its own paths, supporting layers, modules, etc.

🚧 todo

at the moment test is failing.

we need to enable components + imports to register dependencies without being entries - ie. detect unused composables, but if a composable imports from something else, then that should count as that other thing being used

(this may be straightforward)

[danielroe]

this is a valid nuxt entry, believe it or not, and if present nuxt would actually use this

[danielroe]

is there a way to register these paths so any imports into them are respected, but unused exports are detected?

[webpro]

Yes, if I understand correctly, this is the breakdown:

• default behavior: exports of entry files are not reported
• skipExportsAnalysis: false - report unused exports (what you're asking for)
• allowIncludeExports: true - report unused exports only with flag --include-entry-exports/includeEntryExports

[darthf1]

Would be awesome to see this finished :)

[webpro]

What's the status here? Is there still interest in wrapping this up?

[danielroe]

yes! apologies on the long delay.

[webpro]

Took a different stab at this in #1517. If anyone could take it for a spin in their projects, that would be great :)

[yschroe]

Took a different stab at this in #1517. If anyone could take it for a spin in their projects, that would be great :)

Thanks! I tried your PR and for me it worked pretty well and I could already remove a bit of dead code from my project. 👍

A few things I noticed:

• app.config.ts files are marked as unused (in my project this file is inside a nuxt layer folder)
• index.ts from an auto-imported module is marked as unused (for me also inside a nuxt-layer)
• Inside this index.ts I have registered a routeMiddleware via addRouteMiddleware. The middleware file is also marked as unused
• I have a layers/auth/app/types/page-meta.d.ts file to augment the definePageMeta type -> this file is also marked as unused
• Nuxt modules that are added only in the modules property in defineNuxtConfig/nuxt.config.ts are marked as unused dependencies (e.g. @nuxt/image)
• vitest-environment-nuxt is marked as a unlisted dependency if used in vitest.config.ts (via environment: 'nuxt' - see nuxt test-utils. nuxt test-utils are listed in my devDependencies)

Not sure how much I normally would need to use a knip ignore list (if this exists) as I have never used knip outside of this one nuxt project.

[webpro]

Thanks Yannik! This is great feedback. Any chance you could copy-paste it into #1517?

[webpro]

Thanks for the PR, Daniel! It is much appreciated. Using nuxt/kit clearly has some advantages, including at least:

• Catches more entries more reliably.
• Being a peer dependency provides versioned updates alongside project.

Either approach needs to prepare() and requires most/all of what the plugin is currently doing. There are downsides as well:

• Additional overhead of running loadNuxt().
• The "auto imports" feature adds complexity to Nuxt itself. Essentially, that's the reason we're adding a bunch of complexity to Knip and we should minimize that as good as we can.
• Might set a precedent for other frameworks.

By design, Knip has affordances to take what it needs from configuration files with input helpers like toEntry, toConfig, toAlias and there is resolveFromAST to the rescue as well. Tool or framework internals should not be necessary, to keep Knip as lean & mean as possible (tbh Knip isn't that fast to begin with). We currently probably cover >95% of cases in Knip already, and I'm sure we can still do better. Edge cases can usually be covered with a manual entry or ignore* item.

The vision, direction and resources of this project do not align with taking in more of such complexity, and I would prefer not to include the extra dev/peer dependencies. We could still refactor the pull request and skip the new dependencies. Keep the remaining improvements to help the Knip + Nuxt community minimize their required configuration. What do you think?