mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
Saxon FletcherandClaude Opus 5
5198afae61
Every block and starter guide answers "what does this install?" with a file tree. That is the wrong unit: a reader wants to know which tables land in their database, which Edge Functions get deployed, and which URLs their app gains — none of which a path listing states. `common/project-resources` derives that inventory from source text alone. It reads supplied files and returns resources; it never touches a filesystem, fetches, executes SQL or project code, or depends on React, so it is reusable outside the library. Tables come from parsing migration and schema SQL with libpg-query's Postgres 17 grammar, tracking creates, drops, renames and schema moves in path order, rather than pattern-matching CREATE TABLE. Edge Functions read supabase/config.toml with a real TOML parser for custom entrypoints and `enabled = false`. Routes follow each framework's documented file convention — Next.js App and Pages routers, Nuxt, TanStack, React Router's fs-routes, and Flutter — and static route declarations, not guesses. Where the source cannot settle a question the analyzer emits a diagnostic instead of inventing a resource; project-resources/README.md states the scope and limits in full. The library's build runs the analysis once into __registry__/resources.json, which adds a "What's added" tab to every block guide's overview and the matching section to the Markdown export. Community starter templates live in other repositories, so update:starter-sources pins each one to a commit and vendors the SQL and config text it needs to analyze, keeping the build offline and the result reviewable in the diff. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>