mirror of
https://github.com/supabase/supabase.git
synced 2026-10-08 10:55:06 +03:00
claude[bot]andClaude
c30437a58a
<!-- ccr-slack-attribution --> _Requested by **Matt Rossman, Ali Waseem** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1785960993618839?thread_ts=1785960993.618839&cid=C0161K73J1J)_ ## 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? Bug fix. ## What is the current behavior? The Supabase logo in the browser tab looks blurry on high-DPI displays on supabase.com, but sharp on the dashboard. Same logo, same asset files — only the marketing site looks soft. Separately, `genFaviconData()` points one of its `<link rel="icon">` tags at `favicon-128x128.png`, a file that no app in the repo ships. That is a live 404 on docs, learn and ui-library today — and on design-system, which hardcodes its own copy of the same icon list. ## What is the new behavior? The tab icon is sharp on both, and the 404 is gone everywhere. ## Additional context **How.** `apps/www/app/layout.tsx` hardcoded a Next.js `metadata.icons` block that pointed `icon`, `shortcut` and `apple` all at `/favicon/favicon.ico`. That `.ico` contains a single 16x16 layer, so on a 2x display the browser has no 32px candidate to choose and upscales the 16x16 — hence the blur. It only affects App Router routes, which now includes the homepage, `/blog`, `/pricing` and the product pages; www's remaining Pages Router routes already went through the shared component and were fine. www was not using the shared `genFaviconData()` helper from `common/MetaFavicons/app-router`, which docs, learn and ui-library all do. Swapping it in makes www advertise the same 16/32/48/96/128/180/196 PNG ladder the dashboard does, so the browser picks the 32px PNG on a 2x display. The argument is `''` because www serves from the site root (`basePath: ''` in `next.config.mjs`). **Second, related change.** `packages/common/MetaFavicons/app-router.ts` referenced `favicon-128x128.png`; the asset is `favicon-128.png` in every app's `public/favicon/` (the pages-router variant of the helper already had it right). Fixed to match. Without this, wiring www up to the helper would have added a fourth app to the existing 404. **Third, related change.** `apps/design-system/app/layout.tsx` had its own inline copy of `genFaviconData` — byte-identical to the shared one except that it still pointed at `favicon-128x128.png`, so fixing the shared helper alone would have left design-system 404ing. Replaced the 91-line inline copy with the shared import, passing the app's existing `BASE_PATH` (which mirrors `basePath` in its `next.config.mjs`) the same way docs, learn and ui-library do. That removes the last hardcoded icon list among the App Router apps, so the filename can't drift back out of sync. No favicon image assets were added or changed — every file the helper references already exists in both `apps/www/public/favicon/` and `apps/design-system/public/favicon/`. **Possible follow-up.** `favicon.ico` itself is single-layer 16x16 in both www and studio (byte-identical files). Regenerating it as a multi-resolution ICO with 16/32/48 layers would help any consumer that only reads the `.ico` — bookmark bars, some browser surfaces, and notably supabase.com/evals, which is a rewrite to a separate Vercel app and so won't pick up this layout change, but does resolve root-relative icon hrefs against www's `public/`. Left out here because it touches studio's assets too and is a separate call. --- _Generated by [Claude Code](https://claude.ai/code/session_01F2AZs625JxKASYVAj8LWYq)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
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 runs both the Next.js development server and Contentlayer concurrently, which is recommended for most development workflows.
Alternative commands
You can also run the development server and content watcher separately:
# Run only the Next.js development server
pnpm dev:next
# Run only the content watcher (in a separate terminal shell)
pnpm dev:content
Or run the development server from the root directory:
pnpm dev:design-system
To run both the development server and content watcher from the root directory, you can use:
# Run the development server
pnpm dev:design-system
# Run the content watcher (in a separate terminal shell)
pnpm --filter=design-system dev:content
Open http://localhost:3003 in your browser to see the result.
Watching for MDX changes
The dev command automatically watches for changes to MDX files with hot reload. If you're running the pnpm dev:next separately, you'll need to run pnpm dev:content in a separate terminal shell to watch for content changes.
Adding components
The design system references components rather than housing them. That’s an important distinction to make, as everything that follows here is about the documentation of components. You can add or edit components in one of these two places:
packages/ui: basic UI componentspackages/ui-patterns: components which are built using NPM libraries or amalgamations of components frompatterns/ui
There are several parts of this design system that need to be manually updated after components have been added or removed (from documentation). These include:
config/docs.ts: list of components in the sidebarcontent/docs: the actual component documentationregistry/examples.ts: list of example componentsregistry/fragments.ts: list of fragment componentsregistry/charts.ts: list of chart componentsregistry/default/example/*: the actual example components
You will need to rebuild the design system’s registry after making new additions:
cd apps/design-system
pnpm build:registry