Files
supabase/apps/docs
Danny White c0f1ef51fb feat(docs): migrate resources and getting-started to ContentListings (#48517)
## What kind of change does this PR introduce?

Docs update / follow-up to #48379.

## What is the current behavior?

`/guides/resources` and `/guides/getting-started` hand-roll `GlassPanel`
grids in MDX. They look like ContentListings cards after the chrome PR,
but they do not use the shared data files, so they miss PostHog
`docs_content_listing_clicked` telemetry and the CONTRIBUTING
contribution path.

## What is the new behavior?

Those pages use `<ContentListings id="…" />` backed by
`resources.data.ts` and `getting-started.data.ts`, same pattern as
storage.

- Section-level `$Show` wrappers stay for framework / web / mobile
blocks
- Nimbus stays a `$Partial` behind `$Show`
- New optional per-item `feature` field gates SDK links (e.g. Flutter /
Swift / Kotlin) without splitting whole sections
- CONTRIBUTING notes when to use `feature` vs a partial-level `$Show`

## To test

Compare the following against `master`:

-
[Resources](https://docs-git-dnywh-docs-content-listings-resources-239158-supabase.vercel.app/docs/guides/resources):
overview, migrate, and postgres grids; icons in light/dark
- [Getting
started](https://docs-git-dnywh-docs-content-listings-resources-239158-supabase.vercel.app/docs/guides/getting-started):
overview, use cases, framework quickstarts, web demos, mobile tutorials;
nimbus partial when enabled
- Click a card and confirm `docs_content_listing_clicked` fires with the
expected `listingId`

Everything should look and feel the same. It’s just that we’re using
`ContentListings` instead of `GlassPanel` grids.

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

- **New Features**
- Added centralized Getting Started and Resources content listings,
including quickstarts, demos, tutorials, migration guides, and Postgres
resources.
- Added feature-based visibility controls for individual content listing
items.

- **Improvements**
- Disabled content is now automatically hidden from documentation pages
and generated Markdown.
  - Pages and sections with no available content are omitted entirely.
  - External documentation links are more secure.
- Updated contribution guidance with instructions and examples for
feature flags.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-08-03 00:52:44 +00:00
..
2026-07-01 12:59:00 +02:00
2026-07-08 12:30:42 +10:00

Reference Docs

Supabase Reference Docs

Maintainers

If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.

DocSpec

We use documentation specifications which can be used to generate human-readable docs.

  • OpenAPI: for documenting API endpoints.
  • SDKSpec (custom to Supabase): for SDKs and client libraries.
  • ConfigSpec (custom to Supabase): for configuration options.
  • CLISpec (custom to Supabase): for CLI commands and usage.

The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.

Contributing

To contribute to docs, see the developers' guide and contributing guide.