Katerina Skroumpelou
d303c248d3
## 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.
Supabase Library
The library is the documentation and shadcn registry app for Supabase blocks and starter apps. Its workspace package name is library.
Development and checks
Run these commands from the repository root with the repository's Node and pnpm versions:
pnpm --filter library dev
pnpm --filter library test
pnpm --filter library typecheck
pnpm --filter library lint
pnpm --filter library build
The development server runs at localhost:3004/library. build and dev build the registry first, then generate the HTML content, Markdown guides, and llms.txt. Markdown generation reads the completed registry, so these steps must retain that order. Type checking generates Next.js types before running TypeScript and works without a previous development build.
Registry JSON in public/r and the preview index in __registry__ are generated and committed. Regenerate them with pnpm --filter library build:registry; do not edit them by hand. .velite, public/markdown, and public/llms.txt are generated build artifacts. Library CI runs the test suite, checks for registry drift, and builds the app.
Authoring guides
Write documentation in content/docs/<framework>/<slug>.mdx, or content/docs/starters/<slug>.mdx for starter apps. Keep frontmatter for page metadata. Installation headings, prerequisites, commands, and follow-up instructions belong in the MDX body, in the order readers should follow them.
Use BlockItem for a registry installation command. Its name is the published registry item ID. React is the default; Vue and Nuxt pages must select the Vue CLI explicitly:
## Installation
<BlockItem name="password-based-auth-nextjs" />
<BlockItem name="infinite-query-composable" framework="vue" />
The shared command helper supplies both the page and its Markdown export. Vue commands use an absolute registry URL so a fresh project does not need an @supabase alias. Put other commands in ordinary fenced shell blocks. Keep notes next to the command they explain. Use showOpenInV0 on BlockItem when a block supports that action. For Vue and Nuxt blocks that need an existing Supabase client, link the client guide and include a conditional client-install command; let readers reuse an existing client.
The primary Copy prompt action points agents to the canonical /library/docs/<framework>/<slug>.md guide and asks them to prefer the guide's shadcn install command over copying files from registry JSON. It does not repeat installation commands. Starter prompts describe creating a new application; block prompts describe integrating into the existing project. The page also exposes a Markdown link.
The Markdown exporter reads the same MDX body, expands registry commands and file trees, and links each block's registry JSON as its source. Instruction-bearing MDX components need an explicit Markdown handler and a fixture in lib/library-mdx-to-markdown.test.ts. Missing registry files, document references, or unsupported components fail generation.
Register discoverable blocks and starter apps in config/library.ts and the existing navigation definitions in config/docs.ts. The catalog test compares these routes with the actual content directory. Keep intentional omissions explicit in that test.
Supabase types
From this directory, regenerate local database types with:
supabase gen types --local > registry/default/fixtures/database.types.ts