Danny White
1131e3e2ce
## What kind of change does this PR introduce? Bug fix / design-system alignment for the legacy `Button` from `ui`. ## What is the current behavior? Omitting `variant` on the legacy `Button` falls back to brand-green `primary`. That makes accidental greens easy, and it is hard to spot the real main action on busy pages. ## What is the new behavior? - Legacy `Button` now defaults to neutral `default` - Intentional primary CTAs (create, save, submit, marketing CTAs, and matching `ButtonTooltip` usages) now set `variant="primary"` so their appearance is unchanged - Neutral actions that previously relied on the old fallback (cancel, close, back, dashboard nav, and similar) become grey/white - Design-system docs updated; regression tests cover the new default `Button_Shadcn_` is unchanged. It already uses its own CVA default. This is PR 1 of 2 in a stack. PR 2 drops now-redundant `variant="default"` props. ## To test Studio (http://localhost:8082): - `/sign-in`: Sign in stays green - Open a project → Database → Tables: New table stays green - Auth → Users → Invite: Invite user stays green; Cancel / dismiss controls stay neutral - Project Settings → General: edit a field so Cancel and Save appear. Cancel is neutral, Save is green Design system (http://localhost:3003): - Components → Button: default demo is neutral; primary demo is green; featured preview is the default variant Marketing (optional): - www header: Start your project stays green; logged-in Dashboard is neutral <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Style** - Buttons now default to a neutral style, while primary actions across Studio, documentation, marketing pages, forms, dialogs, and error states use prominent primary styling. - Updated button examples and previews clarify the distinction between default and primary variants. - Event registration now includes a directional arrow icon. - **Tests** - Added coverage confirming default button styling and explicit primary styling behave as expected. - Updated related test fixtures to use primary styling where appropriate. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Supabase Design System
Design resources for building consistent user experiences at Supabase.
Getting started
First, make a copy of .env.local.example and name it env.local. Then install any required packages and start the development server:
cd apps/design-system
pnpm i
pnpm dev
The dev command generates __registry__, then runs the Next.js development server and Contentlayer together. That is the recommended workflow.
Alternative commands
You can also run the development server and content watcher separately. Generate the registry first, because dev:next and dev:content do not:
pnpm generate:registry
# Run only the Next.js development server
pnpm dev:next
# Run only the content watcher (in a separate terminal shell)
pnpm dev:content
From the repo root, pnpm dev:design-system runs the same dev script, so it also generates __registry__. If you split the watchers from the root, generate first:
pnpm --filter=design-system generate:registry
pnpm --filter=design-system dev:next
pnpm --filter=design-system dev:content
Open http://localhost:3003 in your browser to see the result.
Watching for MDX changes
The dev command watches MDX files and hot-reloads them. If you are running pnpm dev:next on its own, also run pnpm dev:content in another terminal.
Adding components
The design system references components rather than housing them. That distinction matters: everything below is about documenting components, not implementing them. Add or edit the components themselves in one of these two places:
packages/ui: basic UI componentspackages/ui-patterns: components built from libraries or frompackages/ui
After you add or remove documented components, update these source files:
config/docs.ts: list of components in the sidebarcontent/docs: the component documentationregistry/examples.ts: example componentsregistry/fragments.ts: fragment componentsregistry/charts.ts: chart componentsregistry/copy-writing.ts: copywriting examplesregistry/default/example/*: the example component implementationsregistry/default/block/*: chart block implementations, when you add a chart
Do not edit __registry__. pnpm dev, pnpm typecheck, and pnpm build generate it from the files above, and it is gitignored. If you add registry entries while the app is already running, regenerate it:
cd apps/design-system
pnpm generate:registry