feat: add capabilities based on supabase-js public methods - #18
Closed
mandarini wants to merge 26 commits into
Closed
feat: add capabilities based on supabase-js public methods#18mandarini wants to merge 26 commits into
mandarini wants to merge 26 commits into
Conversation
Replace five monolithic YAML area files with one markdown file per
feature, following a Swift Evolution-style proposal structure.
- `capabilities/areas.yaml` — area registry with titles, descriptions,
and ordered group definitions
- `capabilities/{area}/NNNN-slug.md` — one file per feature; ID is
derived from folder + stem (hyphens → underscores, numeric prefix
stripped); SDK entries are sparse (unlisted = not_implemented)
- `capabilities/TEMPLATE.md` — blank template with HTML comment
guidance for each section; `capabilities/auth/0001-sign-up.md`
serves as the canonical worked example
Spec template sections: Behavior (required), Prerequisites, Errors,
Notes, Related (all optional). Body is reserved for feature
specification; all matrix data remains in YAML frontmatter.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Each auth feature frontmatter now includes an `openapi` block pointing
to supabase/auth openapi.yaml and the specific operation(s) it maps to.
Format:
openapi:
repo: supabase/auth
path: openapi.yaml
operations:
- method: POST
path: "/signup"
- method: POST # optional params for /token variants
path: "/token"
params:
grant_type: password
7 features have no spec operation (client-side only or missing from spec):
set_session, get_claims, on_auth_state_change, restore_session,
mfa_get_aal, mfa_webauthn_update, admin_create_user.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ection The openapi: frontmatter field is replaced by a ## API section in the markdown body, keeping all spec/documentation content in the body and all structured matrix data in the frontmatter. Format in body: ## API Spec: https://github.com/supabase/auth/blob/master/openapi.yaml - `POST /signup` - `POST /token` — `grant_type=password` TEMPLATE.md updated to include ## API as the first body section (optional — omit for client-side-only features). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Rolls back the per-feature markdown structure in response to review
feedback. Restores the original per-area YAML files which naturally
solve ordering (list position), compactness, and cross-feature scanning.
Changes:
- capabilities/{area}.yaml — restored to original per-area structure,
with a new `groups:` block added to each file carrying group titles
and display order (replaces the standalone areas.yaml)
- specs/{area}/{feature_id}.md — new directory for optional per-feature
specs, linked by convention from the feature id (auth.sign_up →
specs/auth/sign_up.md); no explicit field needed in the YAML
- specs/TEMPLATE.md — blank spec template (## API, ## Behavior,
## Prerequisites, ## Errors, ## Notes, ## Related)
- specs/auth/sign_up.md — canonical worked example
This cleanly separates structured machine-readable data (YAML) from
human/LLM-readable specification prose (Markdown).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Draft design for moving SDK compliance data out of the central capabilities YAML and into each SDK's own repository. Key decisions: - supabase-capabilities.yaml at root of each SDK repo (sparse, flat) - Reusable GitHub Actions validation workflow published from this repo - Hourly aggregation workflow fetches compliance via GitHub API - Central YAML becomes pure feature registry (no sdks: block) - No SDK repos touched until team review Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…es.yaml - Add validateCompliance() to check sdk name, feature ids, and statuses - Add normalizeCompliance() to convert sparse YAML entries to ComplianceEntry objects - Add collectFeatureIds() to gather all known feature ids from loaded areas - Update types.ts: add partially_implemented status, Group interface, ComplianceEntry, ComplianceMap; remove SdkEntry/Reference and sdks field from Feature
…compliance files)
… on features) - Remove sdks: blocks from test YAML (schema now has additionalProperties: false) - Fix schema-invalid test to use missing required field instead of partial sdks - Update changedFiles test to verify filtering without reference queries (references moved to compliance files) - Update report mode assertion (parity=1 when no sdks applicable languages)
…ading feature.sdks
…y_implemented rendering
…and site deployment
When a spec file exists at specs/{area}/{stem}.md, the feature name in
the generated matrix becomes a clickable link to the GitHub URL. Hovering
shows a Supabase green underline; default style is subtle dotted underline.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
checkSpecs() errors on any specs/{area}/{stem}.md that has no matching
{area}.{stem} feature in the capabilities YAML, catching orphaned specs
and typos early. Wired into the validate pipeline via the new specsDir
option on RunOptions.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Removes outdated sdks/references instructions and documents the new model: central repo as pure feature registry, SDK compliance in per-repo supabase-capabilities.yaml, partially_implemented status, spec file validation, and the three new CI workflows. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Shorter, clearer name that reads naturally in an SDK repo context. Updated across aggregate.ts, compliance-cli.ts, references.ts, the reusable workflow, and the README. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Remove JS-specific function signature; spec now describes behavior, not a method API surface - Document all inputs per credential type (email vs phone) with a table covering data, captchaToken, channel, and emailRedirectTo - Clarify that redirect_to is a query parameter, not a request body field - Split confirmation flow into two explicit branches (autoconfirm on/off) - Add PKCE subsection with S256 + verifier storage semantics - Document obfuscation behavior for existing confirmed accounts in Notes - Add over_request_rate_limit to Errors Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mandarini
force-pushed
the
feat/add-capabilities
branch
from
June 11, 2026 13:11
02ba733 to
88f548c
Compare
SDK-1045 Bootstrap supabase-js compliance with supabase/sdk capability matrix
Follow-up work after supabase/sdk#15 merges. That PR moves SDK compliance reporting out of the central 1. Write
|
grdsdev
requested changes
Jun 11, 2026
| - id: storage.create_index | ||
| name: Create Index | ||
| description: Creates a new vector index in this bucket Convenience method that automatically includes the bucket name | ||
| group: files |
Collaborator
There was a problem hiding this comment.
this I think should be another group, vector-bucket? How was this named again?
Comment on lines
+125
to
+128
| - id: storage.set_header | ||
| name: Set Header | ||
| description: Set an HTTP header for the request. Creates a shallow copy of headers to avoid mutating shared state. | ||
| group: files |
Collaborator
There was a problem hiding this comment.
I remember storage team mentioning this wasn't needed anymore, I think we could not consider this as canonical feature.
Comment on lines
+129
to
+132
| - id: storage.throw_on_error | ||
| name: Throw On Error | ||
| description: Enable throwing errors instead of returning them. When enabled, errors are thrown instead of returned in { data, error } format. | ||
| group: files |
Collaborator
There was a problem hiding this comment.
JS specific, remove from canonical features
Comment on lines
+133
to
+136
| - id: storage.to_base64 | ||
| name: To Base64 | ||
| description: To Base64 (no description in source). | ||
| group: files |
Collaborator
There was a problem hiding this comment.
I don't remember what this is, should it be a canonical feature?
grdsdev
requested changes
Jun 11, 2026
Comment on lines
+15
to
+18
| - id: database.abort_signal | ||
| name: Abort Signal | ||
| description: Set the AbortSignal for the fetch request. | ||
| group: filter |
Collaborator
There was a problem hiding this comment.
I mean the abort signal naming is JS specific, but I understand this "feature" can be implemented in other languages with different naming, this is the capability of aborting/cancelling a request to postgrest.
In Swift would be similar to:
let task = Task {
try await supabase.from("table").select("*").execute()
}
task.cancel() // No need to specify any "abort signal", cancelling a task is native to the languageThis would be not applicable for Swift, but I wonder if we should have a canonical "cancellation" capability.
Comment on lines
+151
to
+154
| - id: database.override_types | ||
| name: Override Types | ||
| description: Override the type of the returned field in the response. | ||
| group: filter |
Comment on lines
+191
to
+194
| - id: database.returns | ||
| name: Returns | ||
| description: Override the type of the returned . | ||
| group: filter |
Comment on lines
+227
to
+230
| - id: database.throw_on_error | ||
| name: Throw On Error | ||
| description: If there's an error with the query, throwOnError will reject the promise by throwing the error instead of returning it as part of a successful response. | ||
| group: filter |
grdsdev
requested changes
Jun 11, 2026
Comment on lines
+23
to
+26
| - id: realtime.copy_bindings | ||
| name: Copy Bindings | ||
| description: Copy Bindings (no description in source). | ||
| group: channel |
Collaborator
There was a problem hiding this comment.
should not be public exposed I think
Comment on lines
+55
to
+58
| - id: realtime.on | ||
| name: "On" | ||
| description: Creates an event handler that listens to changes. | ||
| group: channel |
Collaborator
There was a problem hiding this comment.
This is a case where it should not be a 1 to 1 mapping to the SDK method, we have 3 separate features here.
- Listen for broadcast messages
- Listen for presence events
- Listen for postgres changes
How should this be represented in the canonical spec?
Option 1: consider 3 separate features
Option 2: consider a single feature, and specify the 3 cases in the spec file
cc : @supabase/sdk for feedback.
Contributor
Author
|
Moved here to avoid having to resolve all these conflicts #19 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Seeds all 5 capability files (auth, database, storage, realtime, functions) from supabase-js's typedoc spec.json — ~200 feature entries with ids, names, descriptions, and groups derived mechanically from the public API surface. Generated by scripts/sync-canon.ts in supabase-js. Future SDKs declare compliance against these IDs; future updates land as additive PRs.