feat: bundle full favicon set as AppShell default

[erickteowarang]

What

AppShell previously shipped a single 32×32 Tailor mark as its bundled default favicon. It now bundles a small, purpose-fit favicon set and injects the whole list when the app mounts:

• favicon-16x16.png / favicon-32x32.png — the browser-tab icons
• apple-touch-icon.png (180×180) — home-screen bookmark icon for both iOS and Android

Each asset is embedded as a base64 data URI, so the set ships in the JS bundle with no asset-copy step in consuming apps.

Deliberately excluded

This is a web app framework, not a PWA, so the following are omitted to keep the bundle small (~14 KB vs ~64 KB for the full favicon_io set):

• favicon.ico — legacy fallback; React 19 doesn't support the browsers that need it, and since we inject a data URI (not a file at /favicon.ico), the browser's auto-fetch never triggers.
• android-chrome-192/512 + site.webmanifest — only consumed via a web manifest for PWA install / Android home-screen. We don't inject a manifest. Android "Add to Home Screen" falls back to the apple-touch-icon, which is kept.

How

• src/lib/default-favicon.ts — a typed DEFAULT_FAVICONS list (data URIs + rel/type/sizes).
• src/components/document-head.tsx — DocumentHead renders the whole DEFAULT_FAVICONS list of <link> tags by default (was one).
• src/lib/favicons/ — raw source files kept for regeneration (in src/, not published — only dist/** ships).
• scripts/gen-favicons.mjs — regenerates the data-URI module from the raw files (node scripts/gen-favicons.mjs).

Backward compatibility

Only the default changed (one → three). No public API break (DEFAULT_FAVICON_HREF was internal-only).

• Passing favicon="…" still replaces the whole set with that single href.
• An existing host-page <link rel="icon"> is still respected (nothing injected).

Testing

• pnpm type-check ✅ · pnpm lint ✅ · pnpm test ✅ (1314 core tests, incl. updated document-head tests) · pnpm fmt ✅
• Verified every embedded data URI round-trips to byte-identical source images.

🤖 Generated with Claude Code

[IzumiSy]

This seems a bit expensive for what is essentially a fallback path. Since DocumentHead is part of the root route, the full base64 favicon set currently ends up in the main app-shell bundle for every consumer, even when they already provide their own favicon or have a host-page icon.

In my local production build, dist/app-shell.js went from roughly 375 kB to 438 kB raw and from 86 kB to 122 kB gzip (about +36 kB gzip), which feels fairly noticeable for a default favicon fallback.

Would it make sense to move the full set behind a dedicated subpath export (for example @tailor-platform/app-shell/favicons) and only load it via dynamic import() when neither a favicon prop nor a host-page icon is present? That would preserve the current default behavior while keeping the main bundle a bit leaner.

[erickteowarang]

Would it make sense to move the full set behind a dedicated subpath export (for example @tailor-platform/app-shell/favicons) and only load it via dynamic import() when neither a favicon prop nor a host-page icon is present? That would preserve the current default behavior while keeping the main bundle a bit leaner.

Good shout out, my issue with lazy-loading all of the favicons is that:

• It's not SSR-friendly if we ever go down that path
• Users will see a flash of the globe icon before the favicon kicks in

I do think there's value in deferring the apple-touch icon (because that one is only used for bookmarks in iOS/Safari, which is post-load), so I'll do that, but for the main favicons, they're like ~2KB combined so I don't think pre-optimising for that is worth the effort.

EDIT: After trying it out, I don't think it's worth adding complexity to chunk/lazy-load just the apple-touch favicon, as it's only 7.45 KB zipped. If you think it's worth it let me know.

[IzumiSy]

Re-checking the latest revision, this is much smaller than when I left the original comment, so I’m happy to retract that concern. Bundling the full set inline seems fine to me now.