mirror of
https://github.com/supabase/supabase.git
synced 2026-10-16 06:39:09 +03:00
550f18b05003073eaa0bca2145801bcdedaacb2e
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Katerina Skroumpelou
|
d303c248d3 |
docs: drop stale alpha labels from server and middleware reference (#51494)
## Problem The server and middleware reference pages on supabase.com still carry alpha labels that were dropped from the source partials weeks ago. #51031 (Sep 30) removed the alpha wording from the partials and #51276 (Oct 5) added the adapter removal date, but neither change reached the live site. The reference build (`apps/docs/scripts/build-reference-content.ts`, `writeNewMarkdownPartials`) copies a partial to `docs/ref/<library>/<name>.mdx` only when that file does not exist, and the page renderer reads from `docs/ref`. Once a page has been seeded, later edits to the partial are never picked up. The three affected pages were seeded before those PRs merged. The UI library MCP page has the same stale wording: it says the `pipeline` entry form of `withSupabase` is alpha and tracks `@supabase/middleware` 0.x. Middleware is at 1.x and `@supabase/server` dropped the alpha label in supabase/server#185. Linear: [SDK-2161](https://linear.app/supabase/issue/SDK-2161/remove-the-public-beta-designation-from-supabaseserver). Companion package PR: supabase/server#192. ## Solution Copy the current partial bodies over their rendered twins. The frontmatter is identical in each pair, and the partials are left untouched: - `apps/docs/docs/ref/server/frameworks.mdx`: adapters are now described as deprecated with the December 1, 2026 removal date, the Versions note tells readers to add `@supabase/middleware` as a direct dependency, the migration steps include `npm install @supabase/middleware`, and "The entry form is alpha" is gone. - `apps/docs/docs/ref/middleware/introduction.mdx`: the "Alpha" admonition is gone. - `apps/docs/docs/ref/middleware/usage-examples.mdx`: the entry form note no longer says alpha. Rewrite one paragraph in `apps/ui-library/content/docs/headless/mcp.mdx` so it states the version requirement (`@supabase/server` 1.6.0 or later) and that the nested form behaves the same, without the alpha or 0.x claims. After this PR each `docs/ref` file is byte-identical to its partial, so `diff` between the two is empty. ## Preview links | Site | Live | Preview | Search for | | ---------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | | Docs | [/docs/reference/server/frameworks](https://supabase.com/docs/reference/server/frameworks) | [/docs/reference/server/frameworks](https://docs-git-docs-drop-stale-alpha-labels-supabase.vercel.app/docs/reference/server/frameworks) | `December 1, 2026` | | Docs | [/docs/reference/middleware/introduction](https://supabase.com/docs/reference/middleware/introduction) | [/docs/reference/middleware/introduction](https://docs-git-docs-drop-stale-alpha-labels-supabase.vercel.app/docs/reference/middleware/introduction) | `is in alpha` (live only) | | Docs | [/docs/reference/middleware/usage-examples](https://supabase.com/docs/reference/middleware/usage-examples) | [/docs/reference/middleware/usage-examples](https://docs-git-docs-drop-stale-alpha-labels-supabase.vercel.app/docs/reference/middleware/usage-examples) | `The entry form of` | | UI library | [/ui/docs/headless/mcp](https://supabase.com/ui/docs/headless/mcp) | [/ui/docs/headless/mcp](https://ui-library-git-docs-drop-stale-alpha-labels-supabase.vercel.app/ui/docs/headless/mcp) | `Composing` | ## Review instructions 1. Open the live and preview links for the frameworks page side by side. Search for `alpha`: present on live, absent on preview. Search for `December 1, 2026`: absent on live, present on preview. 2. Open the middleware introduction. The "Alpha" caution box is gone on preview. 3. Open the middleware usage examples and expand the CORS example details. The entry form note reads "needs `@supabase/server` 1.6.0 or later" with no alpha. 4. Open the UI library MCP page. The paragraph after the `whoami` note states the version requirement and no longer mentions alpha or 0.x. 5. Optional, in a checkout: `diff apps/docs/spec/reference/server/v1/partials/frameworks.mdx apps/docs/docs/ref/server/frameworks.mdx` prints nothing. Same for the two middleware pages. ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [ ] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) The docs text is copied verbatim from partials that already went through review in #51031 and #51276. The one rewritten paragraph in the UI library page follows the Supabase writing style guide. |
||
|
Katerina Skroumpelou
|
d7cac841c4 |
docs: state the adapter removal date in the server frameworks guide (#51276)
The server frameworks guide still said the adapters "will be deprecated soon" and would be "removed in a future major". They have been deprecated since `@supabase/server` 1.9.0, with `@deprecated` tags shipping in 1.9.1, and the removal date is December 1, 2026. This PR updates the two sentences to state that date and drops the wording about the release shape, which is not decided. |
||
|
Katerina Skroumpelou
|
0f453c89fa |
docs: add @supabase/middleware install step to server frameworks guide (#51266)
The framework bridges in the `@supabase/server` reference import `@supabase/middleware` directly, but the guide never said to install it. `@supabase/server` depends on it, so npm and yarn users get it through hoisting, while pnpm users hit "Cannot find module '@supabase/middleware'" the moment they copy a bridge. This PR adds the direct-dependency note to the Versions admonition, an `npm install @supabase/middleware` line to the copy-the-bridge step, and the same instruction to the agent migration prompt. |
||
|
Katerina Skroumpelou
|
2013ebf417 |
docs: drop alpha labels and pin server and middleware imports to a major (#51031)
## Problem `@supabase/middleware` ships as 1.0.0. The docs still label the `pipeline` entry form of `withSupabase` alpha, and several snippets import `npm:@supabase/server` and `npm:@supabase/middleware` with no version or with a `^0.5.0` pin. A snippet without a version leaves readers and tools to guess one, and a guessed version fails on deploy. ## Solution - Removes the alpha wording from the middleware reference intro and usage examples, the server frameworks partial, and the Bring your own MCP guide. The `@supabase/server` 1.6.0 floor stays. - Pins every `npm:@supabase/server` and `npm:@supabase/middleware` import in the guides to a major range, `@1`, following the `npm:@supabase/supabase-js@2` convention in Managing dependencies. - Bumps the authenticated-mcp-server example to middleware `^1.0.0` and server `^1.9.0`. ~~Blocked by supabase/middleware#49. The `@1` range resolves once 1.0.0 is on npm.~~ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated authentication, API key, and MCP examples to use versioned Supabase server and middleware packages. * Clarified that pipeline and nested composition behave the same, and that both require `@supabase/server` 1.6.0 or later. * Removed alpha-status labels from `withSupabase` guidance while retaining the 1.6.0 minimum-version requirement. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Katerina Skroumpelou
|
e1debe9a69 |
docs: add frameworks partial to the server reference (#50514)
Adds a Frameworks partial to the `@supabase/server` reference, after Installing. It explains how to run `@supabase/middleware` entries inside Hono, H3, Elysia, NestJS, and TanStack Start through a copyable bridge, and how to move off the framework adapters: the auth trap (`withRequiredClaims` versus `withClaims`), the `userClaims` to `jwtClaims` field remap, how each framework scopes an entry array to a group of routes, what CORS and body access cost on NestJS, the step-by-step procedure, and a prompt to hand to a coding agent. The bridge code for all five frameworks lives in supabase/server#168 and is linked, not copied. Resolves [SDK-1599](https://linear.app/supabase/issue/SDK-1599) and [SDK-1862](https://linear.app/supabase/issue/SDK-1862): the retired `withSupabase({ middleware })` form is gone from the text. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added integration guidance and setup examples for Hono, H3/Nuxt, Elysia, NestJS, and TanStack Start, including framework-specific context, response, and route-scoping behavior. * Documented migration options for authentication requirements, changes to context and JWT claims, and differences in response and error handling. * Added a TanStack Start bridge example and migration and verification checklists. * Added the frameworks guide to the API reference navigation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Katerina Skroumpelou
|
db63b4d6a2 |
docs: add usage examples partial to the server reference (#50858)
## Problem The `@supabase/server` reference goes straight from Installing to the generated API reference. It has no worked example. The middleware reference has a "Usage examples" page in that spot (#50461). ## Solution A new "Usage examples" partial sits between Installing and the generated reference. It has three examples, taken from the server repo's `docs/getting-started.md`: - **Protect an endpoint with a user JWT:** `withSupabase({ auth: 'user' })`, its CORS handling, and `ctx.supabase` vs `ctx.supabaseAdmin`. - **Serve a public endpoint:** `auth: 'none'`, plus the `verify_jwt = false` setting Edge Functions need. - **Build the context yourself:** `createSupabaseContext` returning `{ data, error }`. Files: - `spec/reference/server/v1/partials/usage-examples.mdx` and its `docs/ref/server/` mirror - `usage-examples` added to `partialsOrder` in `spec/reference/server/v1/config.json` Every claim is checked against the source code in `supabase/server`, `supabase/middleware`, and `supabase/cli`. ## Preview links | Site | Preview | | ---- | ------- | | Docs | [/docs/reference/server/usage-examples](https://docs-git-docs-server-usage-examples-supabase.vercel.app/docs/reference/server/usage-examples) | ## Review instructions 1. Open the preview link. 2. Check that "Usage examples" appears in the sidebar between Installing and the generated reference. 3. Check that the three examples render with the code on the right. ## Checklist - [ ] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added server usage examples for protecting endpoints, serving public endpoints, and creating Supabase context manually. * Documented runtime requirements, JWT verification settings, CORS behavior, and the differences between caller-scoped and admin access. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Katerina Skroumpelou
|
dca96ae929 |
docs: add the Deno optional peer note to the server installing page (#50412)
## 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, one new section on the `@supabase/server` Installing page. ## What is the current behavior? The Deno install instructions stop at `deno add jsr:@supabase/server`. A user who then imports `@supabase/server/middleware/postgres` on Deno or Edge Functions passes `deno check` and fails at startup with `Could not find package 'pg'`, because Deno resolves an optional peer only when the user's own code imports it. Nothing on the page says so. ## What is the new behavior? A new "Optional peer dependencies on Deno" row under the JSR section explains why, shows the bare `import 'pg'` at the top of the entry module, gives the `deno info` check, and notes the `--minimum-dependency-age 0` flag for same-day releases. Both hand-maintained copies of the partial are updated and stay identical: the spec partial for the reference site and the `docs/ref` copy for the markdown build. ## Additional context `pg` is the only optional peer a user can hit today. The MCP entry will add another once it ships and gets documented then. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added Deno installation guidance for Postgres middleware that requires the optional `pg` dependency. * Clarified that importing `pg` directly is necessary for Deno to resolve it at runtime. * Added commands for verifying package resolution and handling Deno’s minimum dependency age checks. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
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> |
||
|
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> |