Repository navigation
feat(config): publish the config schemas as draft-07 under supabase.com/schemas - #7366
Conversation
…om/schemas (CLI-2856) The config, project-config and supabase.lock schemas now declare draft-07 and use $ids under https://supabase.com/schemas/<name>/v1.json. The committed copies move to apps/docs/public/schemas/ to mirror that layout, and a unit test fails on post-draft-07 keywords or drift from the source. readLock accepts locks that still carry the old $schema URL.
There was a problem hiding this comment.
🤖 AI Review
Verified all six input findings and merged the overlapping lock compatibility reports into one, yielding five confirmed findings. The main regression is that newly written or rewritten v1 locks are rejected by older CLIs. Legacy schema assets are also removed without compatibility routes. The remaining findings concern stale paths and duplicated generated definitions.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| 🟠 MAJOR | packages/stack/src/Lock.ts:12 |
backward-compatibility |
claude+codex | Changing the persisted $schema URL while retaining lockfileVersion 1 makes newly written and rewritten locks unreadable by earlier CLIs, breaking shared checkouts and CI pinned to those versions. |
| 🟡 MINOR | apps/docs/public/schemas/config/v1.json:3 |
backward-compatibility |
codex | Moving the published schema assets removes the legacy paths referenced by existing configuration documents and locks without providing compatibility assets or routes. |
| 🟡 MINOR | .gitattributes:31 |
stale-reference |
claude | The generated-file attributes still target deleted public/cli schema paths, leaving the replacement public/schemas files unmarked. |
| ⚪ NIT | apps/docs/public/schemas/supabase-lock/v1.json:305 |
schema-quality |
claude | The newly published lock schema contains eleven identical ServiceLock definitions with numbered names, repeating the resolved-pin structure and unnecessarily expanding the artifact. |
| ⚪ NIT | docs/self-documenting-cli.md:27 |
documentation |
claude | The generator documentation still places schema assets under public/cli/, although generation now writes public/schemas//v1.json. |
Findings outside the diff
- 🟡 MINOR
.gitattributes:31— The generated-file attributes still target deleted public/cli schema paths, leaving the replacement public/schemas files unmarked. - ⚪ NIT
docs/self-documenting-cli.md:27— The generator documentation still places schema assets under public/cli/, although generation now writes public/schemas//v1.json.
Stats
Claude findings: 4 · Codex findings: 2 · Confirmed: 5 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
jgoux
left a comment
There was a problem hiding this comment.
Draft-07 conversion, the new paths and the drift test look right. The affected unit and integration tests pass, and all three committed schemas validate and compile as draft-07. Four small follow-ups are inline.
…2856) The published supabase.lock schema now lists the hosted URL alongside the legacy one in its $schema enum, matching what readLock accepts. The lock tests pin the historical literal, and the README and docs tree describe the draft-07 schemas under public/schemas/.
…(CLI-2864) (supabase#7397) ## Summary Since supabase#7366 the config, project-config and `supabase.lock` schemas have `$id`s under `https://supabase.com/schemas/`, but nothing serves them yet. supabase/supabase#52509 sets up `apps/www/public/schemas` in supabase/supabase, and this publishes to it from every stable release. - New `scripts/publish-schemas.ts` copies the newest version of each schema in `apps/docs/public/schemas` to `apps/www/public/schemas` on a `cli/schemas` branch in supabase/supabase. It only opens a PR (or reuses the open one) when a file changed, and arms auto-merge on it - Before pushing, it checks that each schema is a JSON object, declares draft-07, and has an `$id` matching the URL it'll be served from. Lower versions are never written, and it refuses to publish if supabase.com already serves a newer version or the `cli/schemas` branch changes anything else, so a published version can't be modified - `--dry-run` validates and prints what it would publish without touching supabase/supabase. Release dry runs pass it - The clone, branch, commit and PR steps move into `scripts/publish-pull-request.ts`, shared with `publish-docs-spec.ts`. The CLI reference publisher behaves the same as before - The release `docs` job is now "Publish to supabase.com" and runs both publishers, each without stopping the other. A failed publish adds an error annotation and a step summary line, turns the job red and posts to Slack (new `publish-failure` message). The release itself still succeeds Auto-merge still waits on a code-owner approval, since supabase/supabase `master` requires one and the releaser App can't approve its own PR. The schemas path is owned by `@supabase/cli`, so one of us approves and it merges itself. Making it fully hands-off would need the App added as a bypass actor on that ruleset. There's no `v*.x` branch at the minute, so no cherry-pick is needed. ## Linked issue Closes CLI-2864
Summary
The config, project-config and
supabase.lockschemas declared draft 2020-12, and their$ids pointed atsupabase.com/docs/cli/..., which 404s. Taplo (Even Better TOML) doesn't support anything newer than draft-07, and the schemas only use keywords draft-07 already has. So this moves all three to draft-07, with$ids at the URLs they'll be hosted at.toPublishedJsonSchemaDocumentand the lock schema now go through Effect'sJsonSchema.toDocumentDraft07. That converter turns$defsintodefinitions, rewrites the refs, and throws on anything draft-07 can't represent rather than dropping it$ids move tohttps://supabase.com/schemas/{config,project-config,supabase-lock}/v1.json. Nothing is served there yet. CLI-2865 sets up the path in supabase/supabase and CLI-2864 publishes to it on stable releasesapps/docs/public/cli/*.schema.jsontoapps/docs/public/schemas/<name>/v1.json. That's the same layout as the hosted URLs, so the publisher can copy the folder across as-issupabase.lockkeeps being written with its original$schemavalue, because older CLIs check that field as a literal and would reject anything else. Reads also accept the hosted URL (HOSTED_LOCK_SCHEMA_URL), so a later release can switch writes over once enough CLIs read itapps/cli/scripts/published-schemas.unit.test.tsruns in the existing unit job. It fails when a committed schema:#/$defs/$idthat doesn't match its file pathLockschema. Regenerating it also brings in the current shape (noArtifactPin). The per-serviceServiceLockschemas render identically, so the published schema collapses them into one definitionSchema shape change
@supabase/config/schema.jsonand@supabase/config/project-schema.jsonnow declare draft-07 (http://json-schema.org/draft-07/schema#) and the new$ids.CLI_CONFIG_SCHEMA_URLandPROJECT_CONFIG_SCHEMA_URLchange value to match. The schema bodies are otherwise unchanged. If you validate them with a 2020-12-only validator such asAjv2020, switch to a draft-07 one.Code that uses those constants as a default
$schemanow writes the new URL. Existing$schemavalues in user config files aren't changed.Linked issue
Closes CLI-2856