Analyzer::Javascript::Sveltekit
Inherits Analyzer::Javascript::JavascriptEngine < Analyzer < FileHelper < Reference < Object
SvelteKit is a filesystem-routed framework. Routes live under
src/routes/ and the URL is derived from the directory layout:
src/routes/+page.svelte → GET / src/routes/about/+page.svelte → GET /about src/routes/users/[id]/+page.svelte → GET /users/{id} src/routes/users/+server.ts → exports drive verbs src/routes/[...slug]/+page.svelte → GET /{slug} src/routes/(group)/foo/+page.svelte → GET /foo (group hidden)
Two file kinds matter:
+page.svelte(and the.svx/.mdvariants) — HTML pages, always GET.+page.server.{js,ts}siblings don't add a separate route — they're load functions for the same URL.+server.{js,ts,mjs}— API endpoints. Each named verb export (export async function GET,export const POST = ...) registers a route. Falls back to GET / POST / PUT / DELETE / PATCH when no explicit verb is found, mirroring the Astro / Next.js heuristic.
Out of scope for this first cut: per-handler request-helper
scanning (SvelteKit endpoints take { request, params, cookies, url } — accurate read tracking needs cross-call value flow),
rest parameters with matchers ([id=integer]), and
(group)-with-+layout.server.ts cookie-protected endpoints
(the route still fires; auth tagging is the tagger's job).
Constants
Compiled once per verb — interpolated regex literals would otherwise be rebuilt (full PCRE2 compile) for every method on every file.
SvelteKit param group inside a route segment. Replaced in place so
one segment can hold static text around it (foo-[id], @[user])
and so every form normalizes to {name}:
[id] [id=int] [...rest] [[opt]] [[opt=int]] [[...rest]]
Class methods
Instance methods
Instance-side view of the same declaration. The per-file rescues live on
this base class, which has no way to name the analyzer that is running
inside them, so a skipped file could not be attributed to a tech.
Deriving it from analyzer_for keeps the name written exactly once.