Languages / Svelte, Vue and Astro
Svelte, Vue and Astro code analysis: components, routes and dead code
repowise reads .svelte, .vue and .astro files by projecting their script blocks to TypeScript at the same byte offsets, so imports, calls and health findings point at real lines. SvelteKit and Astro route files are entry points and $lib aliases resolve. Component props are set from markup, so the file-level graph is the dead-code signal for these files.
Last reviewed: November 2026
Full tier
What repowise detects in Svelte, Vue and Astro
Checked against the engine source. Every row runs locally with zero LLM calls.
| Files parsed | .svelte, .vue, .astro |
|---|---|
| Import resolution | Full, through the TypeScript resolver. SvelteKit $lib and # subpath imports, Vue config aliases, directory-index components and router import() specifiers |
| Call graph | Yes, via the TypeScript projection |
| Dead code | Unreachable component files; the unused-export pass is off for these files |
| Health markers | TypeScript complexity map on the projected script |
| Performance markers | The TypeScript and JavaScript dialect |
| Coverage reports | lcov, Cobertura, Clover from Vitest or Jest |
| Frameworks recognised | SvelteKit +page, +layout, +server and +error files, Astro src/pages, Nuxt file conventions |
Specific to this language
How Svelte, Vue and Astro code is read
Same line numbers as your source
The script block of a component is projected to TypeScript in place, keeping byte offsets. A complexity finding or a call edge in Counter.svelte points to the line you see in the editor, not to a generated file.
Components are judged at file level
In Svelte and Vue, an exported variable is usually a prop that the parent sets as a markup attribute, so an import count says nothing about it. repowise reads component liveness from the file-level graph instead: a component file that nothing imports and no route reaches is reported as unreachable, with a confidence.
Routes are entry points
SvelteKit route files (+page, +layout, +server, +error), Astro pages under src/pages and Nuxt convention files are roots, so a route component nobody imports is not reported as unreachable.
Honest comparison
Native Svelte, Vue and Astro tools, and when they are enough
| Tool | What it covers |
|---|---|
| svelte-check | Type errors and unused CSS selectors in Svelte components. |
| vue-tsc | Type checking for Vue single-file components. |
| Knip | Unused files and exports with Svelte, Vue and Astro support through its compilers and plugins. |
| ESLint plugins (eslint-plugin-svelte, eslint-plugin-vue) | Per-file rules, including unused variables and component rules. |
Where repowise adds value
- Component files and the TypeScript, Python or Go backend sit in one graph with one dead-code and health pass.
- Unreachable component files ranked by git history, with the owner named.
- Hotspots and co-change: which components change together and which ones keep breaking.
How to run it
Analyse a Svelte, Vue and Astro repository
From the repository root. Agents get the same results through the get_dead_code, get_health and get_context MCP tools.
uv tool install repowise # or: pipx install repowise
repowise init --yes --no-prose # index the repo, no API key
repowise dead-code --min-confidence 0.7 --safe-only
repowise health --refactoring-targets
npx vitest run --coverage --coverage.reporter=lcov
repowise coverage add coverage/lcov.info
repowise serve # graph, health and dead code in a local dashboardQuestions
What people ask before they try it.
Can repowise find unused Vue or Svelte components?
Yes, at file level. A component file that no other file imports and that is not a route is reported as unreachable, with a confidence. Named exports inside component scripts are usually props set from markup, so the file-level graph is the signal.
Do line numbers match my .svelte and .vue files?
Yes. The script is projected to TypeScript at the same byte offsets, so every finding points at the real line in the component file.
Is Nuxt supported?
Nuxt file conventions are treated as entry points for dead code. There are no Nuxt-specific edges beyond the Vue and TypeScript resolution.
Does repowise send my Svelte, Vue or Astro code to an LLM?
No. Parsing, the call graph, dead code, health scores, performance markers and git history all run locally with zero LLM calls. repowise init --yes --no-prose needs no API key, and the analysis itself makes no network calls. Written documentation prose is the one opt-in step that uses a model, and it can run on a local Ollama model.
Related reading
Index a Svelte, Vue and Astro repository.
Public repositories are free on repowise.dev. The CLI is open source and runs on your machine with no API key.