gen types: PostgrestVersion / __InternalSupabase causes false diffs without schema changes
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- postgresql, typescript
Research direction
Start with the gen types typescript command and compare --linked and --local output for an unchanged public schema. Review how __InternalSupabase.PostgrestVersion is produced and assess the proposed schema-only, stable-output, metadata-separation, and documentation directions. Done should mean schema drift checks do not report changes caused only by PostgREST metadata.
Written by the indexing model from the issue text.
Description
Summary
supabase gen types typescript can produce a different committed file even when the Postgres schema is unchanged. The only diff is often __InternalSupabase.PostgrestVersion.
This makes schema drift checks (CI comparing regenerated types vs committed database.ts) noisy and forces consumers to strip metadata manually.
Motivation / workflow
A common setup:
- Local dev:
supabase gen types typescript --linked --schema public→ commitdatabase.ts - CI (no remote token):
supabase start+supabase gen types typescript --local --schema public→ compare to committed file
We expect the comparison to answer: “Did migrations / schema change?”
Instead, raw output can differ because of PostgREST version metadata, not because tables/columns changed.
Reproduction
CLI version: 2.116.0 (via npx supabase)
-
Generate types from a linked project and commit the file:
npx supabase gen types typescript --linked --schema public > database.tsNote
__InternalSupabase.PostgrestVersion(e.g."14.15"). -
Without changing any migration or remote schema, run the same command again days later:
npx supabase gen types typescript --linked --schema public > database-fresh.ts diff -u database.ts database-fresh.ts -
Observed: diff is only:
- PostgrestVersion: "14.15" + PostgrestVersion: "14.5"Table/column types (
public.Tables.*) are identical. -
Stripping
__InternalSupabase/ normalizingPostgrestVersionyields byte-identical schema output.
Why this hurts
git diffaftergen typessuggests a schema update when there was none- CI drift checks on raw files false-fail unless consumers add custom normalization
- Cross-mode checks (
--linkedvs--local) can differ in metadata even when migrations match
Current workaround
We normalize before compare (strip __InternalSupabase, normalize PostgrestVersion):
const normalize = (src) =>
src
.replace(/\r\n/g, '\n')
.replace(
/\n\s*\/\/ Allows to automatically instantiate createClient with right options\n\s*\/\/ instead of createClient<Database, \{ PostgrestVersion: 'XX' \}>\(URL, KEY\)\n\s*__InternalSupabase: \{\n\s*PostgrestVersion: "[^"]+"\n\s*\}\n/,
'\n',
)
.replace(/PostgrestVersion:\s*"[^"]+"/g, 'PostgrestVersion: "NORMALIZED"')
.trimEnd() + '\n';
This works but shouldn’t be required for “schema unchanged” to mean “types output unchanged (modulo metadata)”.
Related
Proposed directions (any one would help)
--schema-only(or similar) for drift checks: emit/compare onlypublictables/enums, omit__InternalSupabase- Stable cross-mode output:
--linkedand--localproduce comparable files when schema matches - Stable
PostgrestVersionin committed output: e.g. omit from default file, or write metadata to a separate generated file - Document official CI drift-check pattern so teams don’t rely on ad-hoc regex normalization
Happy to provide a minimal repro repo or PR to docs if useful.
Environment
- Supabase CLI: 2.116.0
- Command:
gen types typescript --linked --schema public - Schema: unchanged between runs; only
PostgrestVersionstring changed
- Dominant language
- TypeScript
- Stars
- 2.4k
- Forks
- 531
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 332
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from supabase/cli
-
stack: the HTTP gateway closes idle keep-alive connections after 5 s, so a client whose event loop is blocked gets ECONNRESET (`fetch failed`) on its next requestPossibly taken @7ttp claimed this 3 days ago. Open🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
supabase/cli#6975 · 1 assignee ·
Maintainers usually reply within 1 day
-
📘 Docs supabase/cli
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
stack: functions serve fails without a TTY because the default output format is one it rejectsPossibly taken A pull request linked to this issue is open or already merged. Open🐛 Bug supabase/cli
Difficulty 3/5 Half a day Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
stack: functions serve fails with "Dependent … blocks restart of …" after a plain supabase startPossibly taken A pull request linked to this issue is open or already merged. Open🐛 Bug supabase/cli
Difficulty 4/5 3-5 days Newbie friendliness 38/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
area:ui enhancement issue-form:feature platform:cross-platform review: high
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
1lck/Lithe-IDEA#1092 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
developmentseed/deck.gl-raster#693 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Marker-Inc-Korea/AutoRAG#1801 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day