mirror of
https://github.com/supabase/supabase.git
synced 2026-10-11 12:25:05 +03:00
Ivan VasilovandClaude Opus 4.7
72f57dde89
Finishes the `*-opacity-*` → slash-modifier conversion that the
`@tailwindcss/upgrade` tool couldn't complete because the paired
color/opacity classes weren't always adjacent (intervening tokens,
variant prefixes, or absent base color).
Mechanical same-line paired rewrites (perl):
bg-{color} bg-opacity-N → bg-{color}/N
bg-opacity-N bg-{color} → bg-{color}/N (reversed order)
bg bg-opacity-N → bg/N (bare `bg` alias)
(analogous for border-, ring-, divide-)
Hand-edited ambiguous stragglers:
- Rewrote `{variant}:{prefix}-opacity-N` to `{variant}:{prefix}-{base-color}/N`
where a base color was present on the same element (TriggerSheet,
ExitSurveyModal, UpgradeModal, DeleteProjectModal, CommandMenu,
MultiSelectDeprecated).
- Dropped no-op `bg-opacity-100` / `hover:bg-opacity-100` where the
companion rule already implied full opacity (BillingChangeBadge,
SupportAccessToggle, MobileNavigationBar, Announcement/Badge,
LWAnnouncement, Button link variant).
- Rewrote `hover:border-opacity-30` paired with a later base color to
`hover:border-foreground-muted/30` in Announcement/Badge.
- Reworked ComputeBadge state-open styles: `group-data-[state=open]:
bg-opacity-20` / `ring-2/20` (invalid) → `group-data-[state=open]:
bg-{color}/20 ring-{color}/20` mapped per `smallCompute` branch.
- Migrated `defaultTheme.ts` badge theme: dropped `bg-opacity-10` from
base, applied `/10` to each color variant's bg. Deleted dead `utils`
block (declared but never referenced/exported). Fixed stray `bg-200`
typo → `bg-gray-200/10`.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> (+16 squashed commits)
Squashed commits:
[3f18aa64d5] chore(packages/marketing): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `packages/marketing/`, using the same temporary
`_upgrade-entry.css` pattern. Spurious tailwindcss dep addition was
reverted.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[dfd9039173] chore(packages/dev-tools): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `packages/dev-tools/`, using the same temporary `_upgrade-entry.css`
pattern as the other shared packages. The spurious tailwindcss dep
addition was reverted — this package is a consumer, not a Tailwind
owner.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[f815ff2905] chore(packages/ui-patterns): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `packages/ui-patterns/`. Same temporary `_upgrade-entry.css`
pattern as the `packages/ui` run — added to give the tool a CSS entry
to scan templates against, removed before committing.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[999168249a] chore(packages/ui): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `packages/ui/`. A temporary `_upgrade-entry.css` was added during
the run (with `@import "tailwindcss"` + `@config` bridge to the shared
config) so the tool could discover a CSS entry and drive template
migration across `src/**/*.tsx`; it's removed before committing.
Per-app upgrade runs skip `packages/ui` as "outside repository", so this
is the only way to cover it without running the tool at the workspace
root.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[32cdf2253a] chore(ui-library): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `apps/ui-library/`. Also bundles minor `pnpm-lock.yaml` churn
(peer-dep reshuffling triggered by the tool's install pass).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[bf54bac2f1] chore(lite-studio): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `apps/lite-studio/`. The first attempt failed on an unknown
utility (`text-foreground-light`) because `typography.css` loaded its
own Tailwind context without access to the shared plugin. After
switching to `@reference './app.css'` (the same pattern used in
`apps/studio/styles/typography.css`), the tool ran cleanly.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[e7373cf938] chore(www): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `apps/www/`. Also:
- Bumps `apps/www/package.json` tailwindcss from `^3.4.1` to `^4.2.4`
(www had an explicit dep rather than the catalog reference).
- Fixes a double-slash path glitch the tool emitted in
`apps/www/styles/index.css` (`@config '..//tailwind.config.js'` →
`@config '../tailwind.config.js'`).
- `pnpm-lock.yaml` bundled here as it reflects cumulative dep changes
from www plus the earlier `apps/learn` addition.
The tool warned that `apps/www/postcss.config.js` contains dynamic
JavaScript and was not auto-migrated — that file needs a manual pass
in a follow-up.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[9fcbb5f28c] chore(studio): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `apps/studio/`. Biggest diff of any single app.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[e77b3b9a27] chore(learn): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `apps/learn/`. Also adds `tailwindcss: ^4.2.4` to the app's
package.json (the upgrade tool injects this when the app didn't
previously declare tailwindcss directly).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[5ad834d688] chore(docs): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `apps/docs/`.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[f3101bf306] chore(design-system): run @tailwindcss/upgrade v4 codemods
Automated output from `pnpm dlx @tailwindcss/upgrade --force` executed
within `apps/design-system/`. Handles deprecated-class renames, `@apply`
prefix-bang → suffix-bang syntax, gradient utility renames, and related
v4-aware rewrites. Only files under `apps/design-system/` are touched;
shared packages are skipped by the tool when run from a single app.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[f60e5d01d1] chore: pin tailwindcss to 4.2.4 in all package.json files
Replace `"tailwindcss": "catalog:"` and `"@tailwindcss/postcss": "catalog:"`
with explicit `4.2.4` pins so `@tailwindcss/upgrade` can run without a
catalog-vs-node_modules version mismatch.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[0676c22a12] chore: rename deprecated Tailwind utility classes
Apply the non-opacity class renames from Tailwind v3.4 → v4, across all
source files (`*.tsx`, `*.ts`, `*.jsx`, `*.js`, `*.css`, `*.mdx`),
excluding `examples/` and the vendored `apps/studio/public/monaco-editor`
bundle.
- `flex-grow` → `grow`
- `flex-shrink` → `shrink`
- `overflow-ellipsis` → `text-ellipsis`
- `shadow-sm` → `shadow-xs`
- `rounded-sm` → `rounded-xs`
- `blur-sm` → `blur-xs`
- `outline-none` → `outline-hidden` (preserves v3's accessibility-friendly
behavior; v4's `outline-none` now means `outline-style: none` only)
CSS property syntax (`flex-grow: 1;`, `outline: none;`, etc.) was
protected with a negative lookahead for `\s*:` so raw CSS is untouched.
Opacity utilities (`bg-opacity-*`, `border-opacity-*`, `ring-opacity-*`,
`divide-opacity-*`) and `ring` → `ring-3` are context-dependent and are
deferred to a follow-up commit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[3d8e96069e] Bunch of fixes.
[9dadccf323] Migrate studio.
Co-authored-by: Copilot <copilot@github.com>
[9e706b3092] chore(config): bump Tailwind to v4 via @config bridge
- Bump catalog `tailwindcss` from 3.4.1 to 4.2.3 and add
`@tailwindcss/postcss` 4.2.3.
- Swap shared PostCSS config to `@tailwindcss/postcss` and drop
`tailwindcss/nesting` (v4 handles nesting internally via Lightning
CSS).
- Replace `@tailwind base/components/utilities` with
`@import "tailwindcss"` + `@config "../../packages/config/tailwind.config.js"`
in the 10 app-level CSS entry files (studio, www, docs, design-system,
ui-library, learn, lite-studio). Skips `examples/*` which aren't part
of the monorepo build.
- Remove `<alpha-value>` placeholders from
`packages/config/tailwind.config.js` (4 occurrences) and from
`apps/www/tailwind.config.js` (purple-sos color scale, 9 occurrences).
Trade-off: opacity modifiers like `bg-studio/50` no longer work for
these theme colors — they're used with static classes today.
- Remove `@tailwindcss/container-queries` — it's built into v4. Dropped
from `apps/studio`, `apps/design-system`, `apps/docs` package.jsons and
their Tailwind configs.
Custom plugins (`hit-area`, `motion-safe-transition`), `tailwindcss-radix`,
`@mertasan/tailwindcss-variables`, and `tailwindcss-animate` are kept
as-is; the v3-style `plugin()` / `matchUtilities()` / `addVariant()` APIs
still work under v4. Swapping `hit-area` to the v4-native CSS `@utility`
version and replacing `tailwindcss-radix` with native `data-[state=*]:`
variants is deferred to follow-up PRs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.
Versioning
All tools have versioned docs, which are kept in separate folders. For example, the CLI has the following folders and files:
cli: the "next" release.cli_spec: contains the DocSpec for the "next" release (see below).cli_versioned_docs: a version of the documentation for every release (including the most current version).cli_versioned_sidebars: a version of the sidebar for every release (including the most current version).
When you release a new version of a tool, you should also release a new version of the docs. You can do this via the command line. For example, if you just released the CLI version 1.0.1:
npm run cli:version 1.0.1
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.