mirror of
https://github.com/supabase/supabase.git
synced 2026-10-07 02:15:05 +03:00
codex/fix-tanstack-e2e
14
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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 --> |
||
|
Wen Bo Xie
|
0eb08cb9f0 |
docs: prepare scoped personal access tokens docs for GA (#50839)
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. |
||
|
Miranda Limonczenko
|
7012ba4a55 |
docs(functions): regroup the secrets guide by information type (#50419)
Moves and heading levels only. No claims changed. Studio renders a Docs button at apps/studio/pages/project/[ref]/functions/secrets.tsx:43 pointing at #using-the-cli, but "Using the CLI" was bold text rather than a heading, so the anchor had no target and the button dropped the reader at the top of the page. It and "Using the Dashboard" are now real headings, which repairs it. Local secrets and Production secrets were h3 under "Accessing environment variables", but neither is about accessing one. Both are now h2 siblings, and the reference list moved to the end, so the page runs procedures first and facts last. Sections are ordered by what the reader is doing, not by subject: set a secret locally, read it in code, then set it in production. "Accessing environment variables" sat after production, which put the reading step after the shipping step. Local secrets held a two-item list of the loading mechanisms, which is a fact sitting inside a procedure. It is now the section's opening sentence, where a one-line fact can qualify the procedure without interrupting it. Every existing heading text is unchanged, so #default-secrets, #local-secrets, #production-secrets and #accessing-environment-variables all still resolve. Added a value statement opener, and an outcome after the production procedure. No intro outline: the page is short and its headings already scan. The frontmatter title was title case. Renaming it to sentence case moves a navigation label and a search entry, so the nav entry and the three pages that used the old title as link text change with it. The slug is untouched. |
||
|
Miranda Limonczenko
|
4d2bd0eacf |
docs: add the missing API key decision information (#49799)
Closes DOCS-1311 Closes FDBKIN-2926 Closes DOCS-694 ## 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. Corrections and new content. This is the PR that is to bring the Eval to green. ## What is the current behavior? Two statements are wrong, and the gaps behind most logged confusion about this page are unfilled. - The Availability column marks publishable and secret keys Platform-only. `supabase start` prints both. - The page says Edge Functions only verify the legacy keys and to use `--no-verify-jwt`. #49700 updated `guides/functions/auth-headers` to document that `verify_jwt` accepts the new keys on either header, but left this page and the migration guide stating the old behavior. - The page has no code samples, so it never shows how a key reaches code. An agent reading it falls back on `SUPABASE_SERVICE_ROLE_KEY`, the legacy key this same page deprecates. - Nothing maps `anon` and `service_role` to their replacements, or says the replacements aren't `eyJ`-prefixed JWTs. - The Postgres role table covers only publishable keys. ## What is the new behavior? Corrections: - Mark all four key types available on Platform and CLI, and note that the local secret key takes the place of the local `service_role` key. - Point the Edge Functions guidance at the `@supabase/server` SDK instead of `--no-verify-jwt`. Fix the same bullet in the migration guide. Additions: - "Coming from `anon` and `service_role`" gives the legacy-to-new mapping and says the replacements aren't JWTs. - Extend the Postgres role table to cover secret keys, and note that grants are evaluated before Row Level Security, so a missing grant fails even for `service_role`. - State who does what. Copying a key needs a signed-in Dashboard session, so it is a person's step, while code only refers to the variable name. Add a `.env` sample naming the variables. - Add the two `createClient` samples the page lacked, plus an "Inside an Edge Function" subsection using `withSupabase`, which reads no key from the environment. - Cross-reference from the key decision to retrieving a value, wiring it into code, or migrating an application that ships legacy keys. ## Additional context PR 4 of 4. Base is #49797. ## Manual testing 1. Open the API keys guide on the deploy preview. 2. Check the Key types table. All four rows read "Platform, CLI". 3. Check Known limitations. It no longer mentions `--no-verify-jwt`. 4. Open the migration guide and check Known limitations. The Edge Functions bullet matches. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated API key guidance with clearer instructions for finding, selecting, and using publishable and secret keys. * Added examples for environment variables, client applications, backend code, and Edge Functions. * Clarified key formats, CLI availability, local development output, Postgres role mappings, and authorization behavior. * Expanded guidance on `apikey` headers, RLS errors, and Edge Function API key authorization. * Refined migration guidance for API key authentication in Edge Functions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
5bd0b90cf0 |
docs: add all ways to get an API key (not just Studio) (#49797)
## 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? "Find your keys" offers only the Dashboard. Readers working from a script, a preview branch, or a local stack have no path, which accounts for several logged reports of people unable to locate a key. ## What is the new behavior? Replace the procedure with a tabbed selector so a reader picks the path that matches where they work: - Dashboard, through the Connect dialog or Settings > API Keys. - Supabase CLI, `supabase projects api-keys --project-ref`, including the note that a preview branch has its own keys and needs its own ref. - Management API, `GET /v1/projects/{ref}/api-keys?reveal=true`, for deploy scripts and provisioning tooling. - Local stack, from `supabase start` output or `supabase status`. `queryGroup="retrieval-method"` makes each tab deep-linkable, so a reader can be sent straight to one path. ## Additional context PR 3 of 4. Base is #49796. ## Manual testing 1. Open the API keys guide on the deploy preview and find "Find your keys". 2. Select each tab. One panel shows at a time, and the URL gains `?retrieval-method=<tab>`. 3. Open that URL in a new tab. It restores the same selection. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the API key deprecation guidance to link to the “Find your keys” guide. - Expanded the guide with instructions for retrieving keys through the Dashboard, CLI, Management API, and local stack. - Added guidance to create keys in the Dashboard when none are available. - Reworded the table of contents entry for improved clarity. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
d7f1a44e53 |
docs: restructure the API keys guide by information type (#49796)
## 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. Restructure, mostly moved lines, plus a tense fix in a shared partial. ## What is the current behavior? Context, procedure, and reference material are interleaved, so background reading interrupts the action path. - The page never states which key to use as an answer. You infer it from a five-column reference table. - Finding a key is a fragment inside an admonition, placed above the page's own definition of an API key. - Rotating a leaked key, the only procedure on the page, is the last H3. - The "Changes to API keys" notice narrates a past change in future tense, and "They will be deprecated" has no antecedent in its paragraph. ## What is the new behavior? Group the guide into context, procedure, and reference sections, per CONTRIBUTING § Guides on mixed information types. - Lead with "Which key do you use?", a decision table keyed on where the code runs. Section navigation sits directly below the intro. - Collect the conceptual sections under "How API keys work" and give publishable and secret keys parallel headings. - Promote both procedures into "Find and use your keys". Rotation is now an ordered procedure. - Move the enumerated secret key rules into "Security reference", grouped under bold labels by the kind of mistake each prevents, and leave a short danger admonition where secret keys are introduced. - Promote the five-sentence coexistence admonition to its own section. Admonitions are for short warnings. - Rewrite the shared deprecation partial for timeless documentation: present tense, no dangling "They", no "now". The partial renders on five pages. - Pin a stable anchor on the rotation heading and update the one inbound link, in the rotating-anon-service-and-jwt-secrets troubleshooting entry. - Align link text across docs for this guide. Twenty-one links pointed at it under fourteen labels, including two that named the wrong destination. Rule: when a link means the guide, the text is "API keys"; when it means a specific key or section, the specific text stays. Twelve now share "API keys", up from three. Review with `git diff --color-moved=zebra`. ## Additional context PR 2 of 4. Base is #49795. Includes the link-text alignment previously opened as #49866. ## Manual testing 1. Open the API keys guide on the deploy preview. 2. Check the table of contents. It shows three groups: How API keys work, Find and use your keys, Security reference. 3. Open the rotating-anon-service-and-jwt-secrets troubleshooting entry and follow "Rotate a leaked or compromised key" under Further readings. It lands on the renamed heading. 4. Open the Realtime Broadcast guide and check the "Changes to API keys" notice. It reads in present tense there too. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated API key guidance to explain the transition from legacy `anon` and `service_role` keys to publishable and secret keys by the end of 2026. - Reorganized the API keys guide with clearer key-selection guidance, security recommendations, usage examples, and rotation steps. - Updated troubleshooting references to point to the revised leaked-key rotation guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
2f31010a18 |
docs: style edit for the API keys guide (#49795)
## 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. Style only. ## What is the current behavior? The API keys guide has drifted from `WORD_LIST.md` and `CONTRIBUTING.md`. It also carries two defects: - The rotation steps tell you to replace the new key with the compromised one, rather than the reverse. - The secret key caution list opens with "Do not:" but several items read "Never use" and "Do not pass", which inverts them into the opposite instruction. ## What is the new behavior? Word-level edit. No section is added, moved, or reordered, so the restructure in the next PR of this stack lands as a readable set of moved lines. - Fix the reversed rotation instruction. - Rewrite the caution list so every item completes its "Don't:" stem. - Replace the Silicon Valley character names and trailing ellipses in the responsibility table. - Drop italics used for plain emphasis, parenthetical asides, `etc.`, `&`, the lint-flagged "easy", and existential sentence openers. - Replace "since" and "as" used for cause, and future tense used for current product behavior. ## Additional context PR 1 of 4. Base is `master`. ## Manual testing 1. Open [Understanding API keys](https://docs-git-docs-api-keys-style-edit-supabase.vercel.app/docs/guides/getting-started/api-keys) on the deploy preview. 2. Read the secret key caution list. Every item completes the "Don't:" stem. 3. Read "What to do if a secret key or `service_role` has been leaked or compromised". The order is: create the new key, then replace the compromised key with it. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Rewritten the API keys guide with clearer wording and improved structure. * Clarified how to access API keys through the Connect dialog and distinguished API keys from Supabase Auth. * Updated explanations of publishable and secret keys, including cautions, security best practices, and steps for responding to leaked keys. * Refined guidance on known limitations and compatibility differences. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
0d465e7b5f |
chore(ui): Remove 'tip' from Admonition (#48419)
Closes FE-3966 ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## Problem - The admonition uses both 'tip' and 'note', but the visual distinction has long-ago collapsed. - 'Note' is used far more frequently than 'tip' - The two are very similar and it is confusing to know which one to use when they are visually identical ## Solution Collapse 'tip' and 'note' into one by removing all places where there is 'tip' and updating all references to 'tip' into 'note'. **Note:** This PR also resolves new broken links flagged by the E2E docs checker. It may move to another PR since E2Es keep erroring. ### Specific changes See below for an AI-generated list of changes: - **Type system** — removed `'tip'` from `AdmonitionType`, its `TYPE_TO_VARIANT`/`TYPE_LABEL` entries, and the test case in [`packages/ui-patterns/src/Admonition/](packages/ui-patterns/src/Admonition/) - **Remark plugin** — [remarkAdmonition.ts](apps/docs/lib/mdx/plugins/remarkAdmonition.ts) now maps mkdocs `tip` → `note` - **Lint allowlist** — `tip` dropped from `supa-mdx-lint.config.toml` - **Content migration** — all 109 files with `type="tip"` (across `apps/docs`, `apps/www`, `apps/studio`) converted to `type="note"`; zero remaining hits confirmed by repo-wide grep - **Style guide** — `CONTRIBUTING.md` and `contributing/content.mdx` updated to describe 4 admonition types instead of 5 ### Usage before implementation See the usage table that points toward 'note' as being dominant across all apps: Here's the usage table: | Location | `note` | `tip` | |---|---|---| | apps/docs | ~480 | ~143 | | apps/studio | 34 | 6 | | apps/www (blog) | 19 | 3 | | packages/ui-patterns (tests) | 3 | 1 (parametrized) | | design-system / ui-library / packages/ui / packages/common | 0–1 (test fixture only) | 0 | ## Preview links | App | Page | Search text (Ctrl+F) | Verify | |---|---|---|---| | docs | [/docs/guides/ai-tools/byo-mcp](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/ai-tools/byo-mcp) | official MCP TypeScript SDK | callout's aria-label="Note" | | docs | [/docs/guides/ai-tools/mcp](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/ai-tools/mcp) | MCP server is available at | callout's aria-label="Note" | | docs | [/docs/guides/ai/python-clients](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/ai/python-clients) | Click Connect at the top of any project page | callout's aria-label="Note" | | docs | [/docs/guides/auth/audit-logs](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/auth/audit-logs) | Disabling Postgres storage reduces your database storage costs | callout's aria-label="Note" | | docs | [/docs/guides/database/tables](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/database/tables) | access a custom schema through the Supabase Data API | callout's aria-label="Note" | | docs | [/docs/guides/troubleshooting/edge-function-404-error-response](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/troubleshooting/edge-function-404-error-response) | Always configure an appropriate time frame | callout's aria-label="Note" (was single-quoted type='tip') | | www | [blog: cli-v2-config-as-code](https://zone-www-dot-com-git-admonition-collapse-note-tip-supabase.vercel.app/blog/cli-v2-config-as-code) | Detecting config drift | callout's aria-label="Note" | | www | [blog: cli-v2-config-as-code](https://zone-www-dot-com-git-admonition-collapse-note-tip-supabase.vercel.app/blog/cli-v2-config-as-code) | Setting Edge Function secrets | callout's aria-label="Note" | | www | [blog: nosql-mongodb-compatibility-with-ferretdb-and-flydotio](https://zone-www-dot-com-git-admonition-collapse-note-tip-supabase.vercel.app/blog/nosql-mongodb-compatibility-with-ferretdb-and-flydotio) | If your network supports IPv6 connections | callout's aria-label="Note" | Note: the `www` rows use the `zone-www-dot-com` preview host, not the `docs` one you gave — since blog pages are served from the www app, not docs. ## Manual testing 1. Open preview links for affected pages. 2. Inspect. Open console. 3. Paste the following in and see there is no 'Tip' on the page: ``` document.querySelectorAll('[role="alert"]').forEach(el => console.log(el.getAttribute('aria-label'), el.textContent.slice(0,60))) ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Standardized informational callouts across docs and tutorials from **“Tip”** to **“Note”**, updating multiple examples and guidance blocks. * Updated a few related doc references/links and conditional “Next steps” content. * **UI Updates** * Switched various in-app banners and notices to the **“Note”** style variant. * **Bug Fixes / Improvements** * Removed support for the retired **“Tip”** callout type and aligned docs linting, component behavior, and aria labeling to the remaining admonition types. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Wen Bo Xie
|
5c3d250140 |
docs: clarify that creating new API keys does not disable legacy keys (#47395)
Creating publishable and secret keys adds them alongside the existing anon and service_role keys without affecting them. Make this explicit in two places so users don't assume their legacy keys are revoked: - Add an Admonition note to the API keys guide explaining both key types work simultaneously and legacy keys must be disabled in a separate step. - Update the "Create new API keys" dialog in Studio to reassure users that their existing anon and service_role keys remain valid. |
||
|
|
608040b8cb |
chore(docs) Resolve 'simple' style warnings where applicable (#46966)
Contributes to DOCS-1052 ## 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? Resolves MDX linting errors related to "simple" where it applies. There was a couple cases that did not apply. For example, a product with "Simple" in the name. These changes are made in context, either by removing or using a more descriptive synonym like "minimal" or "basic". ## Tophatting 1. Read each of the diffs. 2. See that the text still makes sense in context. For extra due diligence, you can run `pnpm lint:mdx` locally and see the 'simple' errors that remain and whether they are worth addressing. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **Documentation** * Updated many guide, tutorial, and troubleshooting pages with clearer “basic”/“minimal” wording across setup steps, local testing instructions, security cautions, and RLS guidance. * Refined headings, example descriptions, and inline comments for consistency (including deployment, MCP, metrics API, and search/function phrasing). * Improved readability with small snippet formatting tweaks (whitespace plus import/comment ordering) and added a self-hosting debugging note for Envoy admin endpoints via a short-lived `curl` container. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Chris Chinchilla <chris.ward@supabase.io> Co-authored-by: Nik Richers <nrichers@gmail.com> |
||
|
Chris Chinchillaandfadymak
|
e4f824b835 |
docs: Strengthen keys note (#46578)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Consolidated API key deprecation guidance into a reusable notice for consistent messaging across docs. Announces deprecation of legacy anon/service_role JWT-secret keys by end of 2026, instructs switching to sb_publishable_xxx / sb_secret_xxx, and provides steps to locate and copy both new and legacy keys. Applied across auth, getting-started, API, and realtime guides. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: fadymak <dev@fadymak.com> |
||
|
Tomás PozoandChris Chinchilla
|
4ed75886fc |
docs: guide for migrating to publishable and secret API keys (#46600)
## What Adds a getting-started guide for migrating an existing project from the legacy JWT-based `anon` and `service_role` keys to the new publishable (`sb_publishable_...`) and secret (`sb_secret_...`) keys. The guide walks through the migration step by step: - **Before you start** — maps legacy keys to their replacements. - **Step 1** — create the new `default` keys. - **Step 2 / 3** — swap the publishable key in client code and the secret key in backend code. - **Database Webhooks and `pg_net`** — move the key from the `Authorization: Bearer` header to the `apikey` header (the new keys aren't JWTs and are rejected on `Authorization`), with a Vault note for not inlining secrets. - **Step 4** — update Edge Functions, with two options: read the new env vars (`SUPABASE_PUBLISHABLE_KEYS` / `SUPABASE_SECRET_KEYS`) and set `verify_jwt = false`, or adopt the `@supabase/server` SDK. - **Step 5 / 6** — verify nothing uses the legacy keys, then deactivate them (reversible). - **Next steps** — clarifies that JWT signing keys are a separate, independent migration. ## Notes While writing this we found Studio issues to fix separately (the Invoke Function cURL snippet and the Database Webhooks editor both put the new keys on the `Authorization` header). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a comprehensive migration guide for moving from legacy JWT-based API keys to the new publishable and secret keys with zero‑downtime steps, verification, limitations, and next steps. * Clarified API key behavior and recommended migration actions in the getting‑started docs. * Added a navigation entry linking to the new migration guide. * **Style** * Relaxed documentation lint rules to allow expected wording/phrases (e.g., "backends", "Database Webhooks"). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Chris Chinchilla <chris@chrischinchilla.com> |
||
|
Ivan VasilovandJordi Enric
|
56de26fe22 |
chore: Migrate the monorepo to use Tailwind v4 (#45318)
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> |
||
|
Chris Chinchilla
|
a96d3d2b21 | docs: API landing pages overhaul (#45062) |