|
| 1 | +--- |
| 2 | +'@layerstack/svelte-state': patch |
| 3 | +'@layerstack/svelte-stores': patch |
| 4 | +'@layerstack/tailwind': patch |
| 5 | +'@layerstack/docs': patch |
| 6 | +--- |
| 7 | + |
| 8 | +fix: Stop the fallback settings from stripping the applied theme, and derive `dark:` from the themes. |
| 9 | + |
| 10 | +`getSettings()` builds a fallback outside a `settings()` provider, and that fallback constructed a |
| 11 | +theme store with **no themes configured**. Its constructor still ran, read `localStorage`, wrote |
| 12 | +`<html data-theme="dark">`, and then — because `[].includes('dark')` is false — *removed* the `dark` |
| 13 | +class the real instance had just applied. The result was `data-theme="dark"` with no `dark` class: |
| 14 | +a dark palette with every `dark:` utility still light, most visibly light code tokens on a dark |
| 15 | +background. Whether it happened at all depended on when the fallback was first touched, which is why |
| 16 | +it was intermittent, and why toggling the theme fixed it. |
| 17 | + |
| 18 | +A theme store with nothing configured is now inert — it never touches the document or |
| 19 | +`localStorage`. A stored theme the app no longer defines is also ignored rather than applied, since |
| 20 | +it cannot be classified as light or dark. |
| 21 | + |
| 22 | +The `dark:` variant is now generated from the themes themselves. A theme declares its darkness with |
| 23 | +`color-scheme: dark`, so that is the single source of truth: `@custom-variant dark` lists every dark |
| 24 | +`[data-theme]` alongside `.dark` and the `prefers-color-scheme` fallback. The palette and the variant |
| 25 | +can no longer disagree, whatever JavaScript does. |
| 26 | + |
| 27 | +`@layerstack/docs` moves its Shiki color rules out of `Code.svelte`'s `<style>` block — Svelte |
| 28 | +compiles those, so Tailwind never saw the `dark:` variant there — and into `styles.css`, which also |
| 29 | +covers the runtime-highlighted blocks that the markdown-only rule missed. |
0 commit comments