5 Commits

Include renames

Author	SHA1	Message	Date
Lukas Klingsbo	9f5b36fb3b	docs(dart): OAuth server, custom providers, realtime heartbeat & explain reference updates (#47728) ... > **Stacked on #47994** (`docs/dart-reference-categories-in-yaml`). Review/merge that first; GitHub will retarget this to `master` once it lands. ## What Adds Dart client library reference entries (`apps/docs/spec/supabase_dart_v2.yml`) for features shipped in [`supabase/supabase-flutter`](https://github.com/supabase/supabase-flutter) (parity with `supabase-js`). Rebuilt on the **new reference pipeline** (#47224 / #47994): each method's section comes from `category` / `subcategory` fields on its own YAML entry, with subcategory overviews as committed partials under `spec/reference/dart/v2/partials/`. As a result this PR no longer touches `common-client-libs-sections.json` or `supabase_js_v2.yml` (the earlier shared-nav id rename is unnecessary now that Dart no longer reads that file). ## Changes **Auth (OAuth 2.1 server)** — new **OAuth Server** section - `oauth.getAuthorizationDetails()`, `oauth.approveAuthorization()`, `oauth.denyAuthorization()` **Auth admin** — new **Custom Provider Admin** section - `admin.customProviders.listProviders/createProvider/getProvider/updateProvider/deleteProvider`, including `customClaimsAllowlist` **Realtime** - `onHeartbeat` - `onPostgresChanges` examples for the new pattern/negated filter operators, multiple filters, and column selection **Postgrest** - `explain()` `format` option (`ExplainFormat.text` / `.json`) ## Pipeline plumbing - New partials: `oauth-server.json`, `custom-provider-admin.json` - `generate-dart-reference.ts`: registers `oauth-server-api` and `admin-custom-providers-api` group-header ids in `HEADER_IDS` ## Source PRs supabase-flutter: #1499, #1516, #1517, #1519, #1526 ## Verification `pnpm codegen:references:new` builds cleanly and the nav renders the new **OAuth Server**, **Custom Provider Admin**, and Realtime **onHeartbeat** entries. ## Notes - `RealtimeChannelConfig.replicationReady` (#1526) is omitted since there is no reference slot for channel-config options. - The **OAuth Server** section also appears in #47971 (which adds `listGrants` / `revokeGrant`). Whichever lands second should drop the duplicate section header/partial and keep both sets of methods. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added OAuth 2.1 server consent-flow methods for retrieving, approving, and denying authorization requests. * Added admin APIs for managing custom OIDC/OAuth providers. * Added Realtime heartbeat monitoring and advanced Postgres change filters. * Added text and JSON output options for query explanations. * **Documentation** * Expanded Dart API reference coverage across Auth, MFA, Passkeys, Database, Realtime, and Storage. * Added dedicated reference sections for OAuth Server and Custom Provider administration. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-20 12:35:19 +00:00
Katerina Skroumpelouandgithub-actions[bot]	dac5756295	docs(auth): add server-side package disambiguation guide (#47966) ... Adds a docs guide, "Choosing a server-side package", that explains when to use `supabase-js`, `@supabase/ssr`, or `@supabase/server` when working with Supabase from JavaScript on the server. It includes a decision table and a short code example for each, with one rule up front: cookie-based sessions in SSR frameworks use `@supabase/ssr`, per-request header auth in Edge Functions and other backend runtimes uses `@supabase/server`, and `supabase-js` is the base client both wrap. The guide is surfaced from the Auth overview page and the sidebar, and is cross-linked from the `supabase-js` and `@supabase/server` reference introductions so it is reachable from where developers start. It also states that the packages coexist and are not replacements for each other, and keeps combining `@supabase/server` with `@supabase/ssr` as an advanced section. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added a guide explaining how to choose between Supabase server-side JavaScript packages. - Added the guide to Auth navigation and the getting-started content listings. - Added links to the new guidance throughout relevant JavaScript and server documentation. - **Documentation** - Clarified when to use cookie-based sessions versus header-based authentication. - Added package comparisons, usage examples, advanced guidance, and related next steps. - Updated spelling support for framework names used in the documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-07-16 15:29:00 +03:00
Katerina SkroumpelouandChris Chinchilla	f77e8e75b6	docs: wire @supabase/server v1 into the reference pipeline (#47570) ... ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Docs update. * https://docs-git-docs-wire-server-v1-reference-supabase.vercel.app/docs/reference/server/introduction * <img width="417" height="628" alt="Screenshot 2026-07-06 at 6 13 33 PM" src="https://github.com/user-attachments/assets/9fc27b04-038b-4434-8855-94051f898b5d" /> ## What is the current behavior? `@supabase/server` has no reference documentation page in the Supabase docs. The library publishes a TypeDoc spec to GitHub Pages but the docs pipeline was not wired up to consume it. ## What is the new behavior? - Adds `spec/reference/server/v1/` with a `config.json` (category order: Middleware, Primitives, Adapters, Errors, Types) and `partials/` for the introduction and installing pages. - Adds a `download.server.v1` Makefile target that fetches `https://supabase.github.io/server/spec.json` into `spec/reference/server/v1/server.json`, and wires it into the top-level `download` target so it runs with the rest. - Registers `server-v1` in `SUPPORTS_NEW_REFERENCE_PROCESS` so the build pipeline picks up the new spec directory and generates `content/reference/server/v1/` at build time. - Seeds the generated `docs/ref/server/` partials (introduction and installing) that the reference router serves. ## Additional context The TypeDoc spec is produced by `@supabase/server`'s `docs.yml` workflow on every push to `main`, so `make download.server.v1` will always pull the latest published API surface. The companion PR in the server repo ([supabase/server#95](https://github.com/supabase/server/pull/95)) adds the `@category` tags that the pipeline requires for symbols to appear in navigation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a new **Server SDK** item under **Reference**, linking to `/reference/server` and marked with a **New** badge. * Published **Server Reference v1** documentation for `@supabase/server`, including **Introduction** and **Installing** pages. * **Chores / Improvements** * Enhanced the reference documentation generation to include Server v1 content. * Improved reference detail handling (including clearer TypeDoc output such as **Deprecated** notes). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>	2026-07-07 17:08:51 +03:00
Lukas KlingsboandJeremias Menichelli	833d3cb1d7	docs: migrate Dart/Flutter reference to the new reference pipeline (#47224) ... ## What Routes the **Dart/Flutter v2** reference through the new reference-content pipeline (`scripts/build-reference-content.ts` + `spec/reference/dart/v2/`), the same one JavaScript v2 already uses. Dart v1 stays on the legacy YAML pipeline. ## How Dart has no upstream TypeDoc dump, so this follows the reference README's "adapt other formats as a pre-step" approach: - **`scripts/generate-dart-reference.ts`** converts the committed legacy spec (`spec/supabase_dart_v2.yml`) plus the shared section tree into a TypeDoc-shaped dump at `spec/reference/dart/v2/supabase_flutter.json` (gitignored, like every other dump). Each Dart method becomes a `variant: 'declaration'` node tagged with `@category`/`@subcategory` and carries the legacy function shape (description, notes, params, examples) on a non-TypeDoc `content` field. - **`build-reference-content.ts`** gains a small, backward-compatible addition: it spreads a declaration's `content` straight onto the `functions.json` entry. The renderer then shows params/examples/notes exactly as the legacy YAML did, with no typeSpec round-trip. The field is absent for real TypeDoc dumps, so **JavaScript output is unchanged** (existing JS snapshot still passes). - `dart-v2` added to `SUPPORTS_NEW_REFERENCE_PROCESS`; the v2 `specFile` is dropped from the nav entry so the legacy generator skips it. - Dart search ingest switched to the new-pipeline loader. - `config.json` + hand-authored partials (intro markdown, `initializing`, and subcategory overviews like `using-filters`, `auth-mfa`) added under `spec/reference/dart/v2/partials/`, mirroring the JS lib. - The dart dump is regenerated in `codegen:references:new` and in CI; a self-contained `dart/v2` snapshot test covers the full YAML → dump → content path. ## Verification - `vitest run scripts/build-reference-content.test.ts` — both JS and Dart snapshots pass. - 112 function sections all resolve to renderable `functions.json` entries (104 methods + 7 subcategory overviews + `initializing`). - `tsc --noEmit` clean for all changed files. - Legacy generator confirmed to skip dart v2 (only `dart.v1.*` regenerated). > Note: the live dev server (which needs the Supabase backend) was not run; verification was done at the data-pipeline level plus parity with the production JS pipeline behavior. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added Dart v2 reference documentation sections, including Installing, Initializing, Filters, Modifiers, Auth Admin, MFA, Passkeys, File Buckets, Introduction, and Upgrade guidance. * Expanded the Dart v2 reference pipeline so Dart API pages are generated from the newer reference content flow. * **Bug Fixes** * Improved Dart reference rendering by preserving legacy descriptions, notes, params, and examples in generated function entries. * Updated Dart v2 reference search to use the new pipeline’s generated content so results and navigation stay in sync. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com>	2026-07-03 15:09:56 +02:00
3 people	f20cd22dc3	docs: improve SDK automation build step on docs (#46163) ... # Second try of making a new better process for SDK automation Instead of building a new pipeline. We will take the lessons learned form round 1, plus the good design and improvement on DX quality for drop-in file as a single step required from SDK team and produce almost identical set of files as used right now to render using the current pipeline. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * New reference-content pipeline producing per-library reference artifacts and integrating into prebuilds, search ingestion, and rendering (type-aware examples). * **Documentation** * Added comprehensive JavaScript SDK v2 reference content and partials (Auth MFA, passkeys, admin, TypeScript support, filters, modifiers, Installing, Initializing, Buckets, etc.). * **Tests & CI** * Added regression snapshot test and updated workflows to refresh reference snapshots and ensure spec downloads. * **Chores** * Updated ignore rules, build scripts, Makefile targets, and package lifecycle hooks. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Katerina Skroumpelou <mandarini@users.noreply.github.com> Co-authored-by: Katerina Skroumpelou <sk.katherine@gmail.com>	2026-06-03 11:46:02 +03:00