mirror of
https://github.com/supabase/supabase.git
synced 2026-10-15 22:29:11 +03:00
Introduces `packages/config/tailwind.config.css` as the CSS-first orchestration layer shared by every app. It collects three things that were previously duplicated across every app's main CSS entry: - `@import` of `packages/ui/build/css/source/global.css` — the design system's CSS variable definitions. - `@import` of `dark.css`, `light.css`, and `classic-dark.css` — per-mode overrides for those variables. - `@import` of `packages/config/tailwind-utilities/hit-area.css` — the v4-native `hit-area-*` utility port. And one new thing: - `@custom-variant dark` matching v3's `darkMode: ['class', '[data-theme*='dark']']` — active on `.dark` or `[data-theme*='dark']`, on the element itself or any ancestor, with zero-specificity via `:where()`. Every app's main CSS entry now reads: @import 'tailwindcss'; @import '.../packages/config/tailwind.config.css'; @import './tailwind.config.css'; @config '.../packages/config/tailwind.config.js'; The four duplicated imports (global + three themes + hit-area) disappear from each app's entry file. The `@config` bridge stays for now; the declarative theme still lives in the JS config. The next commit will merge `tailwind.config.js` and `ui.config.js` into a single JS plugin loaded by this CSS file, at which point the `@config` line goes away. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Styles
When to write custom styles
Tailwind should be sufficient to cover the majority of styling needs. We typically only write custom styles here in the event where we're working with an external library and we need to override some styles (e.g Monaco, or even our own UI library).
Ideally, keep custom styling here to a minimum, use tailwind directly in the pages and components where possible, so that we have less code to maintain.
If you're writing custom styles
Group custom styles into separate stylesheets based on their context. For styles which are generic and global, we can write them in main.scss.