Detector::Specification::Supabase
Supabase exposes every table in an exposed schema over PostgREST at
/rest/v1/<table>, so the migration SQL is the API definition.
.sql is a file class no other Noir detector opens, and CREATE TABLE is the most universal statement in SQL — a Rails
db/structure.sql, a Flyway V1__init.sql or any schema dump would
match on content alone. The gate is therefore path-first, in two
tiers:
- under
supabase/->create tableis enough - under
migrations/-> additionally requires an RLS/Supabase fingerprint, because that directory name belongs to every migration tool there is
Bare PostgREST (a Postgres schema with no supabase/ directory) is
deliberately not supported: PostgREST reads the live database and
adds no syntax of its own, so nothing in the file distinguishes a
schema served by PostgREST from any other schema.
Constants
alter table counts too: a migration that only adds a column is
still part of the schema, and dropping those would leave the
emitted params stuck at whatever the first migration declared.
Constructs that only appear in a Supabase/PostgREST-managed schema.
Class methods
The tech name without needing an instance, so the registry can be read off the classes themselves rather than from a parallel list.
Instance methods
Cheap filename-only filter the detector pass uses to skip
detect on files the detector cannot possibly match. The
default true preserves prior behavior (every detector runs on
every file). Override with the same predicate the body of
detect starts with — e.g., filename.ends_with?(".py") for a
Python framework detector — so the detector loop avoids the
detect dispatch on files outside the detector's language.
On large codebases (saleor's 4255 .py files) this lifts ~100
virtual detect calls per file out of the hot loop because
most detectors' inner first-line is exactly this kind of cheap
filename check.
Memo safety: applicable? consults the path
(supabase/ and migrations/ gates), not just the basename.