Scoped personal access tokens are leaving alpha. Remove the pre-GA
framing
and update pages that assumed every token carries full account access.
- Personal Access Tokens guide: remove the public alpha / early access
admonition. Add a section on using a scoped token with the Supabase CLI:
the browser flow of `supabase login` creates a classic token, while
SUPABASE_ACCESS_TOKEN or `supabase login --token` uses a scoped one, and
commands that connect with the database password aren't limited by the
token's permissions.
- Management API introduction: replace "PATs carry the same privileges
as
your user account" with the scoped vs. classic distinction and link to
the
guide's permission tables.
- MCP guide: the CI setup now asks for a scoped token limited to the
connected project and links to the MCP tool permissions table.
- API keys guide: replace the internal "fine-grained token" permission
ID
with the names shown in the dashboard (API Keys, Read), and note that
`reveal=true` in the example also needs API Key Secrets (Read).
- Managing environments: recommend a scoped token for the GitHub Actions
deploy workflow.
## What kind of change does this PR introduce?
bug fix in kotlin documentation
## What is the current behavior?
on scroll within the kotlin documentation, in the installing section a
codeblock collide with the one below
## What is the new behavior?
- fixes by updating mdx markup
| state | preview |
| -------|------|
| before | <img width="862" height="344" alt="image"
src="https://github.com/user-attachments/assets/29332b51-dd88-458c-be12-c450ae6d32f1"
/> |
## Test
1. visit [kotlin
documentation](https://supabase.com/docs/reference/kotlin/installing)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Improved the layout of Ktor installation guidance by separating engine
setup instructions from the multiplatform example.
- Applied the updated structure consistently across Kotlin installation
documentation versions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## See the changes
*
https://docs-git-docs-middleware-usage-examples-supabase.vercel.app/docs/reference/middleware/usage-examples
*
https://docs-git-docs-middleware-usage-examples-supabase.vercel.app/docs/reference/middleware/build-your-own
## 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.
## What is the current behavior?
The `@supabase/middleware` reference has two hand-written pages,
Introduction and Installing, followed directly by the generated API
reference. There is no worked example of composing middleware and no
guidance on writing one. The authoring guide lives only in the
[middleware
repo](https://github.com/supabase/middleware/blob/main/docs/authoring-guide.md).
## What is the new behavior?
Two new partials sit between Installing and the generated reference:
- **Usage examples**: two `pipeline` examples. The first composes
`withCors` and `withFeatureFlag` from `@supabase/middleware`. The second
adds `withSupabase` from `@supabase/server`: `withCors` first,
`withSupabase({ auth: 'user', cors: 'disabled' })` second, and an
environment-driven flag last. The prose explains why a CORS layer must
precede the auth gate, what `withSupabase` does for CORS on its own, and
that the entry form of `withSupabase` is alpha and needs
`@supabase/server` 1.6.0 or later.
- **Build your own middleware**: the `defineMiddleware` shape (four type
arguments, when `run` receives the config, contribute vs short-circuit,
reading `getEnv` inside the per-request function), composing a custom
entry in `pipeline`, what `pipeline` checks at compile time, and when
`satisfies FetchHandler` matters. It links to the full authoring guide
for tests, packaging, and the variants.
`partialsOrder` in `spec/reference/middleware/v1/config.json` registers
both partials. The `docs/ref/middleware/` mirrors were generated with
`pnpm codegen:references:new`.
## Additional context
- Every snippet typechecks against `@supabase/middleware` and
`@supabase/server` source on `main`. The "fails to compile" statements
were confirmed with negative typechecks (duplicate key, unmet
prerequisite, in both the `pipeline` and nested forms).
- The second example's request flow was exercised end to end with a
local JWKS: preflight `204`, missing credentials `401`, flag off `404`,
flag on `200`, and the reversed order producing a `401` with no CORS
headers.
- The generated `sections.json` lists the four partials in order:
Introduction, Installing, Usage examples, Build your own middleware. No
local render check was done.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added usage examples for composing middleware pipelines with CORS,
feature flags, authentication, and Supabase.
* Added guidance for creating custom middleware, contributing request
context, handling responses, and accessing runtime environment
variables.
* Documented middleware ordering, validation, preflight handling, and
authentication behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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 -->
## 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 fix, one sentence removed from the `@supabase/middleware` reference
intro.
## What is the current behavior?
The alpha admonition says the `middleware` option on `withSupabase` in
`@supabase/server` is also alpha. That option was removed in
`@supabase/server` 1.6.0, where `withSupabase` became a `pipeline`
entry, so the sentence describes something that no longer exists.
## What is the new behavior?
The admonition keeps the `@supabase/middleware` alpha wording and drops
the sentence about the removed option. Both hand-maintained copies of
the intro are updated and stay identical: the spec partial that renders
the reference site, and the `docs/ref` copy that feeds the markdown
build.
## Additional context
Same two-file pattern the `@supabase/server` reference uses for its
intro and installing partials.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated middleware documentation to clarify that only the
`@supabase/middleware` package is in alpha.
- Removed the alpha-status notice for the `withSupabase` middleware
option in `@supabase/server`.
- Clarified that `@supabase/middleware` APIs may change between 0.x
releases.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
Documentation update: add a new page for the C# SDK reference v8.0.0
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added C# client reference documentation for version 8.1.0.
* Added navigation for the C# Reference v8 documentation.
* Documented authentication, database, Realtime, Storage, filtering, and
query APIs with C# examples.
* **Documentation**
* Added C# SDK 8.0.0 and 8.1.0 release notes, including breaking
changes, new capabilities, and bug fixes.
* Updated documentation version listings and search coverage for C# v8.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Wire middleware sdk docs (`@supabase/middleware`)
https://github.com/supabase/middleware
Preview ref here:
https://docs-git-docs-supabase-middleware-sdk-supabase.vercel.app/docs/reference/middleware/introduction
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a Middleware SDK reference section to the documentation.
* Added installation guidance for npm, Yarn, pnpm, Deno, and Bun.
* Documented framework-agnostic middleware composition, typed shared
context, ordering, trust, and environment access across supported
runtimes.
* Added Middleware documentation to navigation and search.
* Identified the Middleware SDK as an alpha release.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
Updates docs around scoped PAT's.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Clarified that temporary database access uses a Personal Access Token
as the Postgres role password.
* Updated API documentation to explain that Personal Access Tokens
support custom expiration rather than being described as long-lived.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What
Brings the C# client reference in line with `supabase-csharp` 1.5. The
reference spec had drifted ~2 years and was missing most of the Auth,
MFA, Admin, and Storage surface.
## Changes
- **Fix example errors** in the v1 reference spec — corrected the
`From<T>()`/`Table<T>()` model example, `ListenType` realtime enum, a
mislabeled code fence, and other small mismatches.
- **Backfill release notes** from 1.0.1 through 1.5.0, reconstructed by
diffing the `Supabase.csproj` dependency pins across git tags and
pulling highlights from each sub-package changelog.
- **Document the undocumented API surface** (~27 new entries): Auth
(anonymous, ID token, SSO, refresh, link/unlink identity, code exchange,
reauthenticate, scoped sign-out), the full MFA API, the Admin API via
`AdminAuth`, and Storage (`Copy`, signed URLs, signed uploads).
- **Fix a latent bug**: the `ResetPasswordForEmail()` entry used a spec
id that matched no canonical section, so it never rendered. Renamed to
`reset-password-for-email`.
## Notes
- All signatures verified against the 1.5 SDK source.
- Entries render only when their spec id matches a slot in the shared
`common-client-libs-sections.json`; ids were mapped against that set.
- Spec YAML is Prettier-clean under the repo config.
Closes SDK-1369.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added C# release notes covering versions 1.0.1–1.5.0.
* Updated C# client documentation with current initialization patterns
and expanded authentication, session, identity, PKCE, MFA, Realtime,
Storage, and admin operation examples.
* Added Storage examples for file copying, signed URLs, signed uploads,
and uploads through signed URLs.
* Corrected code samples and clarified scoped sign-out and
password-reset guidance.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
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>
## 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>
# 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>
## What kind of change does this PR introduce?
Docs update. Related to DEPR-551.
## What is the current behavior?
Docs MDX still uses the legacy `label` prop for Admonitions, even though
#45618 added `title` and kept `label` only as a backwards-compatible
alias after #45302 was reverted in #45535.
## What is the new behavior?
Migrates Docs-owned Admonitions from `label=` to `title=` without
changing rendered copy, component APIs, Studio callsites, design-system
examples, or the legacy `label` alias.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Standardized admonition headings across the docs by switching how
admonition headings are provided (preserving all visible guidance and
examples). Content and instructions remain unchanged; this ensures
consistent rendering of callouts and improves uniformity across guides
and reference pages.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46053?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
This PR migrates the whole monorepo to use Tailwind v4:
- Removed `@tailwindcss/container-queries` plugin since it's included by
default in v4,
- Bump all instances of Tailwind to v4. Made minimal changes to the
shared config to remove non-supported features (`alpha` mentions),
- Migrate all apps to be compatible with v4 configs,
- Fix the `typography.css` import in 3 apps,
- Add missing rules which were included by default in v3,
- Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot
of classes
- Rename all misnamed classes according to
https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all
apps.
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
Updates our documentation pages around the Data API to include
instructions on how to grant the necessary privileges across API roles
across tables and functions. Current behaviour means this is largely
unnecessary as privileges are granted by default on public schema, but
adding instructions will help cover scenarios where this isn't the case
and expose some of the underlying magic happening.
## To test:
- These updates refer to new settings that are added to the data api
that give more visibility and control over what tables and functions are
accessible via the api.
- To view these settings you'll need enable `tableEditorApiAccessToggle
` feature flag
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a new "Data API" guide and removed the old "Hardening the Data
API" page
* Updated navigation links to surface the new Data API guide
* Expanded quickstarts, SDK install pages, and security guides with
step‑by‑step Data API exposure, default‑privileges, RLS guidance, and
SQL GRANT examples (including function EXECUTE notes)
* Updated troubleshooting references and added redirects for legacy
documentation paths
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: SaxonF <1072756+SaxonF@users.noreply.github.com>
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Co-authored-by: Chris Chinchilla <chris@chrischinchilla.com>
## 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?
Updates verbiage throughout docs to use postgres over postgresql.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated terminology throughout documentation, guides, and resources
for consistent product naming across all user-facing materials,
including page titles, descriptions, and reference documentation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR fixes some prettier issues:
- Bump and unify all prettier versions to 3.7.3 across teh whole repo
- Bump the SQL prettier plugin
- When running `test:prettier`, check `mdx` files also
- Run the new prettier format on all files
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## What kind of change does this PR introduce?
Documentation and copy corrections.
## What is the current behavior?
Several docs and one Studio file contain grammar, spelling, and
capitalization issues:
- JS v1 upgrade guide: "we'll continuing" (should be "we'll continue"),
"Some the [PR]" (should be "See the [PR]"), extra space before comma
- Realtime docs: "PostgresSQL" (should be "PostgreSQL") in 2 files
- Kotlin SDK installing docs: "Websockets" (should be "WebSockets"),
"Checkout the" (should be "Check out the")
- Broadcast guide: "Websockets" (should be "WebSockets") in code
comments (5 occurrences)
- Prisma troubleshooting: "Checkout this" (should be "Check out this")
- Edge function template: "Websocket Server Example" (should be
"WebSocket Server Example")
## What is the new behavior?
All grammar, spelling, and capitalization issues are corrected:
- **Grammar**: "we'll continue" (verb tense), "See the [PR]" (correct
word), removed extra space
- **Spelling**: "PostgreSQL" (correct product name)
- **Capitalization**: "WebSocket" / "WebSockets" follows the official
W3C/IETF naming convention
- **Word splitting**: "Check out" as a phrasal verb (two words), vs
"checkout" the noun
## Files changed (8)
- `apps/docs/docs/ref/javascript/v1/upgrade-guide.mdx` — grammar fixes
(3 issues)
- `apps/docs/docs/ref/self-hosting-realtime/introduction.mdx` —
PostgresSQL -> PostgreSQL
- `apps/docs/docs/ref/realtime/realtime.mdx` — PostgresSQL -> PostgreSQL
- `apps/docs/docs/ref/kotlin/v2/installing.mdx` — WebSockets + Check out
- `apps/docs/docs/ref/kotlin/installing.mdx` — WebSockets + Check out (2
occurrences)
- `apps/docs/content/guides/realtime/broadcast.mdx` — Websockets ->
WebSockets (5 occurrences)
- `apps/docs/content/troubleshooting/prisma-error-management-Cm5P_o.mdx`
— Check out
- `apps/studio/components/interfaces/Functions/Functions.templates.ts` —
WebSocket template name
## What kind of change does this PR introduce?
Documentation / text fix (grammar)
## What is the current behavior?
Several places in the codebase use "a" before acronyms that start with
vowel sounds, which is grammatically incorrect:
- "enter a MFA code" (MFA is pronounced "em-eff-ay", starting with a
vowel sound)
- "a SMS with a OTP" (SMS = "ess-em-ess", OTP = "oh-tee-pee")
## What is the new behavior?
Corrected to use "an" before acronyms with vowel sounds:
- "enter an MFA code"
- "an SMS with an OTP"
## Files changed
- `apps/studio/data/profile/mfa-challenge-and-verify-mutation.ts` -
comment fix
- `apps/docs/content/guides/platform/multi-factor-authentication.mdx` -
user-facing docs
- `apps/docs/docs/ref/javascript/v1/upgrade-guide.mdx` - code comment in
example
- `apps/docs/docs/ref/dart/v0/upgrade-guide.mdx` - code comment in
example
## Additional context
The rule: use "an" before acronyms pronounced with an initial vowel
sound, regardless of the first letter. "MFA" starts with "em" (vowel
sound), "SMS" starts with "ess" (vowel sound), "OTP" starts with "oh"
(vowel sound).
Partials are currently defined via MDX includes. This PR switches to pre-compile-time partials, which have a new syntax:
```
<$Partial path="path/to/file.mdx" />
```
## Rationale
This produces two improvements:
1. Partial substitution can occur in pipelines that don't use MDX compilation. For example, we can now do partial substitution before building the search index, so partial content will also be indexed.
2. After the App Router migration, the MDXProviders should've been deprecated, but were kept around for the sole reason of making partials work, and leading to us shipping unnecessary client-side code. We get a minor decrease in overall client bundle size (5.74 MB to 5.6 MB) by getting rid of the Providers.
## Breaking changes
Besides the change to partial syntax, the arguments are also less powerful than before because we are doing string substitution and don't have the full power of JS. Defining string variables is still possible (documented in the Contributing guide), and since that's all we actually do in practice, this shouldn't be too cumbersome. There is always the escape hatch of making a custom component for more complex content reuse cases.
Migrates client SDK References to App Router. (Management and CLI API references aren't migrated yet, nor are self-hosting config references.)
Some notes:
Big changes to the way crawler pages are built and individual section URLs (e.g., javascript/select) are served. All of these used to be SSG-generated pages, but the number of heavy pages was just too much to handle -- slow as molasses and my laptop sounded like it was taking off, and CI sometimes refuses to build it all at all.
Tried various tricks with caching and pre-generating data but no dice.
So I changed to only building one copy of each SDK+version page, then serving the sub-URLs through a response rewrite. That's for the actual user-visible pages.
For the bot pages, each sub-URL needs to be its own page, but prebuilding it doesn't work, and rendering on demand from React components is too slow (looking for super-fast response here for SEO). Instead I changed to using an API route that serves very minimal, hand-crafted HTML. It looks ugly, but it's purely for the search bots.
You can test what bots see by running curl --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" <URL_OF_PAGE>
Also added some smoke tests to run against prod for the crawler routes, since we don't keep an eye on those regularly, and Vercel config changes could surprise-break them. Tested the meta images on Open Graph and all seems to work fine.
With this approach, full production builds are really fast: ~5 minutes
Starts using the new type spec handling, which is better at finding params automatically, so I could remove some of the manually written ones from the spec files.
* exclude dart, python, and swift from error codes menu
* Update the error code doc to be client lib agnostic
* run formatter
* Add a filter to filter out section items
* Update apps/docs/components/Navigation/NavigationMenu/NavigationMenuRefList.tsx
* docs: move error codes table in a separate component
* Add auth error codes section for kotlin
Fix missing typo in the api introduction document
Changes text from `Authorization Bearer <supabase_personal_token` to `Authorization Bearer <supabase_personal_token>`
Wen Bo Xie
