extract_astro fed the whole .astro file to the JS grammar. The template is
not JS, so every page reported a syntax error (usually at line 1-2) and
symbols tree-sitter could not recover past the template were dropped.
Blank everything outside the frontmatter and JS <script> bodies (keeping
newlines so locations still match, as _vue_mask_non_script does) and parse
with the TS grammar, Astro's default. Scripts with a non-JS type
(application/ld+json, ...) are blanked too. The existing regex import
rescue is unchanged.
Fixes#2788. Covers the unmasked-script half of #3337.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit fe07657fe1)
Astro files have a `---...---` TypeScript frontmatter block at the top
containing nearly all imports, followed by an HTML-with-expressions
template body, and optionally `<script>` blocks for client-side JS.
Feeding the whole file to the JS tree-sitter parser produces a top-level
ERROR node because the template isn't valid JS, so `import_statement`
nodes are never reached.
Mirrors `extract_svelte` (#713) — same regex-rescue strategy:
- Dynamic `import('...')` pass over the full source.
- Static `import X from '...'` pass over the frontmatter block plus any
`<script>` blocks.
Both static and dynamic imports honor tsconfig.json path aliases and
resolve relative paths through `_resolve_js_module_path` so node ids
match the targets that `_extract_generic` produces for sibling files.
Wired in:
- `detect.py:27` — `.astro` added to `CODE_EXTENSIONS`.
- `extract.py:5492` — `".astro": extract_astro` in the dispatch table.
Tests in `tests/test_astro_extraction.py` cover: extension registration,
frontmatter static imports, dynamic import in frontmatter, client-side
`<script>` block imports, frontmatter-less pages (must not crash), and
tsconfig.json path-alias resolution.
Kevin