Feature request: .astro support in CODE_EXTENSIONS
Package: graphifyy v0.7.16
Use case: Astro marketing/content site with dynamic routing and a Sanity CMS backend (~60 .astro files for the entire page resolver, layouts, and section components)
What
detect.py:27 lists 19 source extensions including .vue and .svelte, but not .astro. Result: every .astro file is silently dropped from the AST pass. Verified on my repo — graphify update . --force ran on 374 files, 0 of them .astro:
$ python3 -c "import json; g=json.load(open('graphify-out/graph.json'));
print('astro nodes:', sum(1 for n in g['nodes'] if '.astro' in n.get('source_file','')))"
astro nodes: 0
In my repo that means the page resolver (src/pages/[...slug].astro), every page, and every section component (src/components/Sections/*.astro) — i.e., the entire rendering layer — is invisible. Queries like "how does Sanity section type X render?" dead-end at the API boundary because the graph has no nodes downstream of it.
Why it matters
Astro has had GitHub-trending traction since 2024 and is the default static-site framework on Vercel/Netlify quickstart paths. With .mdx accepted (closes #428) and .vue/.svelte already supported (#254), .astro is the conspicuous remaining gap for the modern static-site ecosystem.
Suggested approach
Tree-sitter has a community grammar at virchau13/tree-sitter-astro. It parses the frontmatter (TS), HTML body, and embedded expressions. Same shape as the existing .vue/.svelte SFC handling.
Minimum-viable change (parity with .vue support):
# detect.py:27
CODE_EXTENSIONS = {
..., '.vue', '.svelte', '.astro', ...
}
Plus the grammar registration wherever .vue/.svelte are wired in for the SFC extraction path. Extracting just the frontmatter <script> block and the component-name imports would cover ~80% of the cross-file edges; full HTML/expression parsing is a stretch goal.
Workaround in the meantime
For users on Astro sites — document the gap in CLAUDE.md/AGENTS.md so the assistant falls back to grep for rendering questions. Not user-friendly but unblocks.
Feature request:
.astrosupport inCODE_EXTENSIONSPackage:
graphifyyv0.7.16Use case: Astro marketing/content site with dynamic routing and a Sanity CMS backend (~60
.astrofiles for the entire page resolver, layouts, and section components)What
detect.py:27lists 19 source extensions including.vueand.svelte, but not.astro. Result: every.astrofile is silently dropped from the AST pass. Verified on my repo —graphify update . --forceran on 374 files, 0 of them.astro:In my repo that means the page resolver (
src/pages/[...slug].astro), every page, and every section component (src/components/Sections/*.astro) — i.e., the entire rendering layer — is invisible. Queries like "how does Sanity section type X render?" dead-end at the API boundary because the graph has no nodes downstream of it.Why it matters
Astro has had GitHub-trending traction since 2024 and is the default static-site framework on Vercel/Netlify quickstart paths. With
.mdxaccepted (closes #428) and.vue/.sveltealready supported (#254),.astrois the conspicuous remaining gap for the modern static-site ecosystem.Suggested approach
Tree-sitter has a community grammar at
virchau13/tree-sitter-astro. It parses the frontmatter (TS), HTML body, and embedded expressions. Same shape as the existing.vue/.svelteSFC handling.Minimum-viable change (parity with
.vuesupport):Plus the grammar registration wherever
.vue/.svelteare wired in for the SFC extraction path. Extracting just the frontmatter<script>block and the component-name imports would cover ~80% of the cross-file edges; full HTML/expression parsing is a stretch goal.Workaround in the meantime
For users on Astro sites — document the gap in
CLAUDE.md/AGENTS.mdso the assistant falls back to grep for rendering questions. Not user-friendly but unblocks.