Suggest an idea for Knip
- SvelteKit 2.62.0 introduced an alternative way to directly configure SvelteKit in Vite (
vite.config.js) without svelte.config.{js|ts}
- this will also land in SvelteKit v3 (and SvelteKit's migration CLI will offer migrating the SvelteKit config to Vite as an option; this is what surfaced the new gap today)
Hence, Knip's SvelteKit plugin needs to be extended to discover alternative SvelteKit config from Vite config.
I've read the contributing guide and the development guide and am working on a PR which should land within the the next 24h.
Since the Vite-config approach is optional, deciding to use it is an intentional decision by the user. However, svelte.config.{js|ts} might be kept at the same time (e.g. for providing extra-config to Eslint / eslint-plugin-svelte),
Hence, I would argue that Knip's plugin discovery should pick VIte's SvelteKit config over the established config if both config patterns are discovered / exist at the same time. This is in compliance with SvelteKit's own de-deduping.
Suggest an idea for Knip
vite.config.js) withoutsvelte.config.{js|ts}Hence, Knip's SvelteKit plugin needs to be extended to discover alternative SvelteKit config from Vite config.
I've read the contributing guide and the development guide and am working on a PR which should land within the the next 24h.
Since the Vite-config approach is optional, deciding to use it is an intentional decision by the user. However, svelte.config.{js|ts} might be kept at the same time (e.g. for providing extra-config to Eslint / eslint-plugin-svelte),
Hence, I would argue that Knip's plugin discovery should pick VIte's SvelteKit config over the established config if both config patterns are discovered / exist at the same time. This is in compliance with SvelteKit's own de-deduping.