Analyzer::Javascript::Astro
Inherits Analyzer::Javascript::JavascriptEngine < Analyzer < FileHelper < Reference < Object
Astro is a filesystem-routed framework. Routes live under
src/pages/ and the URL is derived from the file path:
src/pages/index.astro → GET / src/pages/about.astro → GET /about src/pages/users/index.astro → GET /users src/pages/users/[id].astro → GET /users/{id} src/pages/[...slug].astro → GET /{slug} (catch-all) src/pages/api/users.ts → exports drive verbs
Page files (.astro, .md, .mdx, .html) are HTML pages —
always GET. API route files in src/pages/api/** (.ts, .js,
.mjs, .tsx, .jsx) export named verb handlers
(export async function GET(...), export const POST = ...).
When no explicit verb export is found we fall back to the
standard handler set (GET / POST / PUT / DELETE / PATCH) — same
heuristic the Next.js analyzer uses for catch-all handlers.
Out of scope for this first cut:
- Astro endpoints under non-conventional
src/pages/roots (the path detection is hard-coded to/src/pages/). - Per-handler request-helper scanning — Astro endpoints use
standard
Request(request.headers.get(...),request.json(),await request.formData()) but resolving reads accurately needs cross-call value tracking. Path placeholders still surface via the optimizer.
Constants
Look for explicit verb exports first
(export const GET = ... / export async function POST() {}),
then fall back to the cross-method catch-all set.
Compiled once per verb — interpolated regex literals would otherwise
be rebuilt (full PCRE2 compile) for every method on every file.
Lowest-cost defaults for endpoints whose handler doesn't advertise its verbs explicitly. Mirrors the Next.js fallback.
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.