supabase

38,871 Commits 1,781 Branches 62 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Saxon Fletcher Claude Opus 5 Ivan Vasilov	3e79df3ece	feat(library): serve the block catalog as Markdown and harden the exporter (#50370 ) ## 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? Feature, bug fix. Part 3 of 6 in a stack that splits the library redesign into reviewable pieces. ## What is the current behavior? An agent can already fetch any guide as Markdown, but has no way to find out what guides exist: the entry point is a rendered React page. The exporter also fails quietly in ways that ship wrong output rather than failing the build: - An unknown component silently unwraps to its children, so a component rename drops its rendered content. - A registry item that cannot be read produces a page with no file listing. - A link to a missing page produces a 404 URL. - An unrecognized install framework produces a plausible command for the wrong CLI. - Only absolute `/library/docs` links are rewritten, so in-page anchors and sibling links break in the export. ## What is the new behavior? `/library` negotiates Markdown the same way the guides do — `Accept: text/markdown`, or an explicit `/library/index.md` — and returns a categorized catalog with every block, its description, its framework variants, and a link to each guide's Markdown. `config/library.ts` is the single catalog description the generator reads, and a test ties it to the content directory in both directions: a guide cannot be added without a catalog entry, or listed without a guide. Each quiet failure above now throws, and links resolve against the page they appear on and are checked against the set of published documents. ```bash curl -H 'Accept: text/markdown' https://supabase.com/library ``` ## Additional context `config/library.ts` also carries the category and preview metadata the redesigned homepage consumes in the last PR of the stack; here it is exercised by the Markdown index and its test. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Added a browsable library catalog covering categories, blocks, starter apps, and supported frameworks. - Added Markdown versions of the library homepage and documentation for compatible tools and workflows. - Added framework-aware links and expanded registry information, including dependencies and source details. - Markdown requests now work for the homepage and documentation, while browser requests continue receiving HTML. - Bug Fixes - Improved document link handling, metadata validation, slug consistency, and detection of duplicate or missing documentation entries. - Tests - Added coverage for catalog routes, Markdown generation, homepage negotiation, document parsing, and framework-specific links. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>	2026-09-22 14:14:04 +02:00
Saxon Fletcher Claude Opus 5 Ivan Vasilov	abbac3b852	refactor(library): resolve registry dependencies from one source of truth (#50367 ) ## 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? Refactor, bug fix. Part 1 of 6 in a stack that splits the library redesign into reviewable pieces. This one is the foundation the rest build on and has no visual change. ## What is the current behavior? Three build steps each reimplement "where does this registry file land in the user's project": `process-registry`'s `getDefaultPath`, `registry/utils`' `uniqBy` on `file.path`, and the Markdown exporter. They disagree, which produces real bugs: - A Vue block whose files come from `node_modules/@supabase/vue-blocks/` keeps its package path, so the installer writes the package folder into the user's project. - `registryItemAppend` builds its `docs` string from `(item.docs, items.flatMap(...))` — a comma expression, so the item's own docs are discarded. - A name collision between a block file and its client's file silently keeps one of the two. - Install commands guess the CLI family from substrings in the item name, so `infinite-query-composable` — a Vue block with neither "vue" nor "nuxtjs" in its name — gets the React CLI. - Production Vue installs use `@supabase/<name>`, but the `@supabase` namespace is registered with shadcn, not shadcn-vue. - `build:registry`, `build:content`, `build:markdown` and `build:llms` run in parallel, but the last three read `public/r`. ## What is the new behavior? `lib/registry-resolution.ts` owns installed-path derivation, first-party dependency naming, deduplication, and cycle detection, and every consumer calls it. `build-registry` validates the whole registry against shadcn's schema and resolves every item, so a broken reference fails the build instead of shipping. `clean-registry` throws rather than logging past a failure. Pages declare their install `framework` explicitly instead of it being inferred, and production Vue installs use the absolute registry URL. The build steps are serialized behind `build:prepare`, and a new `library-tests.yml` workflow runs the library's tests, checks the generated registry is committed, and builds the app. ## Additional context Regenerated registry artifacts are the mechanical result of the resolution fix — the Vue client items and the OAuth consent items that gained their client's docs. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Added explicit React and Vue framework selection for library blocks and installation commands. * Improved registry resolution, dependency handling, path validation, and Vue file normalization. * Added support for reliable local, preview, and production registry URLs. * Documentation * Updated Vue and Nuxt installation documentation to identify the Vue framework explicitly. * Bug Fixes * Preserved combined documentation and validated generated registry content more consistently. * Tests * Added coverage for installation commands, registry resolution, dependency handling, and generated artifacts. * Chores * Added automated pull-request checks for library tests and builds. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>	2026-09-18 10:38:48 +10:00
Saxon Fletcher Cursor Saxon Fletcher Claude Opus 5	bf60e6cdce	feat(library): serve agent-readable markdown for each docs page (#49567 ) ## 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? Feature: agent-readable markdown pages for the UI library docs. ## What is the current behavior? Library docs are HTML-only. `llms.txt` lists page titles, but there is no `.md` body an agent can fetch. ## What is the new behavior? Each docs page is also served as markdown: - Build-time MDX → markdown (`pnpm --filter library build:markdown`) - `GET /library/docs/{slug}.md` (and `Accept: text/markdown`) - HTML pages advertise `rel=alternate` `text/markdown` - `llms.txt` links to the `.md` URLs This is the base of a stack. The prompt-tab PR sits on top: https://github.com/supabase/supabase/pull/49566 ## Additional context Interactive previews are omitted from the markdown. `BlockItem` emits the production `npx shadcn add` command so agents still get an install path. ## To test 1. `pnpm --filter library dev` (generates markdown in `predev`). 2. Open http://localhost:3004/library/docs/nextjs/password-based-auth.md — markdown with the install command, file tree, and setup steps; no interactive previews. 3. Open the same path without `.md` — HTML docs unchanged (no prompt tab in this PR). 4. `curl -H 'Accept: text/markdown' http://localhost:3004/library/docs/nextjs/password-based-auth` should also return markdown. 5. http://localhost:3004/library/llms.txt — links should end in `.md`. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Documentation pages are available as Markdown through `.md` URLs and a dedicated endpoint. * Markdown is generated automatically during development and production builds. * Generated content preserves front matter, links, callouts, installation instructions, and supported documentation elements. * Installation commands support npm, pnpm, yarn, and bun for React and Vue projects. * Bug Fixes * Improved Markdown file handling, link rewriting, and content negotiation. * Tests * Added coverage for Markdown conversion, content negotiation, and installation commands. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 11:35:55 +10:00

Author

SHA1

Message

Date

3e79df3ece

feat(library): serve the block catalog as Markdown and harden the exporter (#50370 )

## 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?

Feature, bug fix.

Part 3 of 6 in a stack that splits the library redesign into reviewable
pieces.

## What is the current behavior?

An agent can already fetch any guide as Markdown, but has no way to find
out what guides exist: the entry point is a rendered React page.

The exporter also fails quietly in ways that ship wrong output rather
than failing the build:

- An unknown component silently unwraps to its children, so a component
rename drops its rendered content.
- A registry item that cannot be read produces a page with no file
listing.
- A link to a missing page produces a 404 URL.
- An unrecognized install framework produces a plausible command for the
wrong CLI.
- Only absolute `/library/docs` links are rewritten, so in-page anchors
and sibling links break in the export.

## What is the new behavior?

`/library` negotiates Markdown the same way the guides do — `Accept:
text/markdown`, or an explicit `/library/index.md` — and returns a
categorized catalog with every block, its description, its framework
variants, and a link to each guide's Markdown.

`config/library.ts` is the single catalog description the generator
reads, and a test ties it to the content directory in both directions: a
guide cannot be added without a catalog entry, or listed without a
guide.

Each quiet failure above now throws, and links resolve against the page
they appear on and are checked against the set of published documents.

```bash
curl -H 'Accept: text/markdown' https://supabase.com/library
```

## Additional context

`config/library.ts` also carries the category and preview metadata the
redesigned homepage consumes in the last PR of the stack; here it is
exercised by the Markdown index and its test.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Added a browsable library catalog covering categories, blocks, starter
apps, and supported frameworks.
- Added Markdown versions of the library homepage and documentation for
compatible tools and workflows.
- Added framework-aware links and expanded registry information,
including dependencies and source details.
- Markdown requests now work for the homepage and documentation, while
browser requests continue receiving HTML.

- **Bug Fixes**
- Improved document link handling, metadata validation, slug
consistency, and detection of duplicate or missing documentation
entries.

- **Tests**
- Added coverage for catalog routes, Markdown generation, homepage
negotiation, document parsing, and framework-specific links.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>

2026-09-22 14:14:04 +02:00

abbac3b852

refactor(library): resolve registry dependencies from one source of truth (#50367 )

## 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?

Refactor, bug fix.

Part 1 of 6 in a stack that splits the library redesign into reviewable
pieces. This one is the foundation the rest build on and has no visual
change.

## What is the current behavior?

Three build steps each reimplement "where does this registry file land
in the user's project": `process-registry`'s `getDefaultPath`,
`registry/utils`' `uniqBy` on `file.path`, and the Markdown exporter.
They disagree, which produces real bugs:

- A Vue block whose files come from `node_modules/@supabase/vue-blocks/`
keeps its package path, so the installer writes the package folder into
the user's project.
- `registryItemAppend` builds its `docs` string from `(item.docs,
items.flatMap(...))` — a comma expression, so the item's own docs are
discarded.
- A name collision between a block file and its client's file silently
keeps one of the two.
- Install commands guess the CLI family from substrings in the item
name, so `infinite-query-composable` — a Vue block with neither "vue"
nor "nuxtjs" in its name — gets the React CLI.
- Production Vue installs use `@supabase/<name>`, but the `@supabase`
namespace is registered with shadcn, not shadcn-vue.
- `build:registry`, `build:content`, `build:markdown` and `build:llms`
run in parallel, but the last three read `public/r`.

## What is the new behavior?

`lib/registry-resolution.ts` owns installed-path derivation, first-party
dependency naming, deduplication, and cycle detection, and every
consumer calls it. `build-registry` validates the whole registry against
shadcn's schema and resolves every item, so a broken reference fails the
build instead of shipping. `clean-registry` throws rather than logging
past a failure.

Pages declare their install `framework` explicitly instead of it being
inferred, and production Vue installs use the absolute registry URL.

The build steps are serialized behind `build:prepare`, and a new
`library-tests.yml` workflow runs the library's tests, checks the
generated registry is committed, and builds the app.

## Additional context

Regenerated registry artifacts are the mechanical result of the
resolution fix — the Vue client items and the OAuth consent items that
gained their client's docs.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Added explicit React and Vue framework selection for library blocks
and installation commands.
* Improved registry resolution, dependency handling, path validation,
and Vue file normalization.
* Added support for reliable local, preview, and production registry
URLs.

* **Documentation**
* Updated Vue and Nuxt installation documentation to identify the Vue
framework explicitly.

* **Bug Fixes**
* Preserved combined documentation and validated generated registry
content more consistently.

* **Tests**
* Added coverage for installation commands, registry resolution,
dependency handling, and generated artifacts.

* **Chores**
  * Added automated pull-request checks for library tests and builds.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>

2026-09-18 10:38:48 +10:00

bf60e6cdce

feat(library): serve agent-readable markdown for each docs page (#49567 )

## 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?

Feature: agent-readable markdown pages for the UI library docs.

## What is the current behavior?

Library docs are HTML-only. `llms.txt` lists page titles, but there is
no `.md` body an agent can fetch.

## What is the new behavior?

Each docs page is also served as markdown:

- Build-time MDX → markdown (`pnpm --filter library build:markdown`)
- `GET /library/docs/{slug}.md` (and `Accept: text/markdown`)
- HTML pages advertise `rel=alternate` `text/markdown`
- `llms.txt` links to the `.md` URLs

This is the base of a stack. The prompt-tab PR sits on top:
https://github.com/supabase/supabase/pull/49566

## Additional context

Interactive previews are omitted from the markdown. `BlockItem` emits
the production `npx shadcn add` command so agents still get an install
path.

## To test

1. `pnpm --filter library dev` (generates markdown in `predev`).
2. Open http://localhost:3004/library/docs/nextjs/password-based-auth.md
— markdown with the install command, file tree, and setup steps; no
interactive previews.
3. Open the same path without `.md` — HTML docs unchanged (no prompt tab
in this PR).
4. `curl -H 'Accept: text/markdown'
http://localhost:3004/library/docs/nextjs/password-based-auth` should
also return markdown.
5. http://localhost:3004/library/llms.txt — links should end in `.md`.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Documentation pages are available as Markdown through `.md` URLs and a
dedicated endpoint.
* Markdown is generated automatically during development and production
builds.
* Generated content preserves front matter, links, callouts,
installation instructions, and supported documentation elements.
* Installation commands support npm, pnpm, yarn, and bun for React and
Vue projects.

* **Bug Fixes**
* Improved Markdown file handling, link rewriting, and content
negotiation.

* **Tests**
* Added coverage for Markdown conversion, content negotiation, and
installation commands.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

2026-09-01 11:35:55 +10:00