@tenphi/tasty 0.0.0-snapshot.30a8b13 → 0.0.0-snapshot.320aa48

package/README.md

@@ -6,7 +6,7 @@
 
 <p align="center">
   <strong>Deterministic styling for stateful component systems.</strong><br>
-  A design-system styling engine that compiles component states into mutually exclusive selectors.
+  A design-system styling engine that compiles component states into mutually exclusive selectors, so complex components stay predictable as they evolve.
 </p>
 
 <p align="center">
@@ -23,6 +23,8 @@ It compiles state maps into **mutually exclusive selectors**, so for a given pro
 
 That is the core guarantee: component styling resolves from declared state logic, not from source-order accidents or specificity fights.
 
+The practical payoff shows up later: adding states, variants, and overrides stays inside the state map instead of reopening selector logic by hand.
+
 Tasty fits best when you are building a design system or component library with intersecting states, variants, tokens, sub-elements, responsive rules, and extension semantics that need to stay predictable over time.
 
 On top of that foundation, Tasty gives teams a governed styling model: a CSS-like DSL, tokens, recipes, typed style props, sub-elements, and multiple rendering modes.
@@ -35,6 +37,7 @@ On top of that foundation, Tasty gives teams a governed styling model: a CSS-lik
 ## Why Tasty
 
 - **Deterministic composition, not cascade fights** — Stateful styles resolve from the state map you declared, not from selector competition. See [How It Actually Works](#how-it-actually-works).
+- **Easier to extend over time** — When components gain new states, variants, or overrides, you update declared branches instead of re-deriving selector interactions by hand.
 - **Built for design-system teams** — Best fit for reusable component systems with complex state interactions.
 - **A governed styling model, not just syntax sugar** — Design-system authors define the styling language product teams consume.
 - **DSL that still feels like CSS** — Familiar property names, less selector boilerplate. Start with the [Style DSL](docs/dsl.md), then use [Style Properties](docs/styles.md) as the handler reference.
@@ -42,8 +45,8 @@ On top of that foundation, Tasty gives teams a governed styling model: a CSS-lik
 ### Supporting capabilities
 
 - **Typed style props and mod props** — `styleProps` exposes selected CSS properties as typed React props (`<Space flow="row" gap="2x">`); `modProps` does the same for modifier keys (`<Button isLoading size="large">`). Both support state maps and full TypeScript autocomplete. See [Style Props](#style-props) and [Mod Props](#mod-props).
-- **Runtime, SSR, and zero-runtime options** — Use `tasty()` for runtime React components, add SSR integrations when your framework renders that runtime on the server, or use `tastyStatic()` when you specifically want build-time extraction instead of runtime styling.
-- **Broad modern CSS coverage** — Media queries, container queries, `@supports`, `:has()`, `@starting-style`, `@property`, `@keyframes`, and more. Features that do not fit the component model (such as `@layer` and `!important`) are intentionally left out.
+- **Server-compatible by default, zero client JS in server-only contexts** — All `tasty()` components and style functions are hook-free. In server-only rendering (Next.js RSC, Astro without islands, SSG), they produce zero client JavaScript with the full feature set. Add SSR integration only when your app also has client-side hydration. Use `tastyStatic()` only when you need build-time extraction without React.
+- **Broad modern CSS coverage** — Media queries, container queries, `@supports`, `:has()`, `@starting-style`, `@property`, `@keyframes`, `@font-face`, `@counter-style`, `@function`, and more. Features that do not fit the component model (such as `@layer` and `!important`) are intentionally left out.
 - **Performance and caching** — Runtime mode injects CSS on demand, reuses chunks aggressively, and relies on multi-level caching so large component systems stay practical.
 - **TypeScript-first and AI-friendly** — Style definitions are declarative, structurally consistent, and fully typed, which helps both humans and tooling understand advanced stateful styles without hidden cascade logic.
 
@@ -79,7 +82,7 @@ For the fuller docs map beyond the quick routes above, start here:
 - **[Comparison](docs/comparison.md)** — read this first if you are evaluating whether Tasty fits your team's styling model
 - **[Adoption Guide](docs/adoption.md)** — understand who Tasty is for, where it fits, and how to introduce it incrementally
 - **[Getting Started](docs/getting-started.md)** — the canonical onboarding path: install, first component, optional shared `configure()`, ESLint, editor tooling, and rendering mode selection
-- **[Style rendering pipeline](docs/PIPELINE.md)** — see the selector model behind deterministic style resolution
+- **[Style rendering pipeline](docs/pipeline.md)** — see the selector model behind deterministic style resolution
 - **[Docs Hub](docs/README.md)** — choose docs by role and task: runtime, zero-runtime, runtime SSR integration, design-system authoring, internals, and debugging
 - **[Methodology](docs/methodology.md)** — the recommended component model and public API conventions for design-system code
 
@@ -188,7 +191,7 @@ Use `configure()` once when your app or design system needs shared aliases, toke
 </Space>
 ```
 
-See [Style Props](#style-props) and [Mod Props](#mod-props) below, or the full reference in [Runtime API](docs/runtime.md#style-props).
+See [Style Props](#style-props) and [Mod Props](#mod-props) below, or the full reference in [React API](docs/react-api.md#style-props).
 
 ## Choose a Styling Approach
 
@@ -196,16 +199,17 @@ Once you understand the component model, pick the rendering mode that matches yo
 
 | Approach | Entry point | Best for | Trade-off |
 |----------|-------------|----------|-----------|
-| **Runtime** | `@tenphi/tasty` | Interactive apps with reusable stateful components and design systems | Full feature set; CSS is generated on demand at runtime |
-| **Zero-runtime** | `@tenphi/tasty/static` | Static sites, SSG, landing pages | Requires the Babel plugin; no component-level `styleProps` or runtime-only APIs |
+| **Runtime (default)** | `tasty()` from `@tenphi/tasty` | All React apps — server-rendered by default, zero client JS until you need interactivity | Full feature set; CSS computed during React rendering (server or client) |
+| **Runtime + SSR integration** | Add `@tenphi/tasty/ssr/*` | Apps with client-side hydration (Next.js client components, Astro islands) | Adds CSS deduplication, FOUC prevention, and client cache hydration |
+| **Zero-runtime** | `tastyStatic()` from `@tenphi/tasty/static` | Non-React frameworks or when you need build-time extraction without React | Requires the Babel plugin; no component-level `styleProps` or runtime-only APIs |
 
-If your framework can execute runtime React code on the server, you can also add **SSR on top of runtime** with `@tenphi/tasty/ssr/*`. This uses the same `tasty()` pipeline, but collects CSS during server rendering and hydrates the cache on the client. That is the model for Next.js, generic React SSR, and Astro islands. See [Getting Started](docs/getting-started.md#choosing-a-rendering-mode), [Zero Runtime](docs/tasty-static.md), and [Server-Side Rendering](docs/ssr.md).
+All `tasty()` components are hook-free and work as React Server Components. In server-only contexts — Next.js RSC without `'use client'`, Astro without `client:*` directives, and other SSG setups — they produce the same end result as `tastyStatic()` (static HTML + CSS, zero client JavaScript) but with the full feature set including `styleProps`, sub-elements, and variants. SSR integration is only needed when your app also has client-side rendering. See [Getting Started](docs/getting-started.md#choosing-a-rendering-mode), [Zero Runtime](docs/tasty-static.md), and [Server-Side Rendering](docs/ssr.md).
 
 ## How It Actually Works
 
 This is the core idea that makes everything else possible.
 
-For the end-to-end architecture — parsing state keys, building exclusive conditions, merging by output, and materializing selectors and at-rules — see **[Style rendering pipeline](docs/PIPELINE.md)**.
+For the end-to-end architecture — parsing state keys, building exclusive conditions, merging by output, and materializing selectors and at-rules — see **[Style rendering pipeline](docs/pipeline.md)**.
 
 ### The structural problem with normal CSS
 
@@ -363,7 +367,7 @@ Compound components can style inner parts from the parent definition with capita
 
 Sub-elements share the root state context by default, so keys like `:hover`, modifiers, root states, and media queries resolve as one coordinated styling block. Use `@own(...)` when a sub-element should react to its own state, and use the `$` selector affix when you need precise descendant targeting.
 
-See [Runtime API - Sub-element Styling](docs/runtime.md#sub-element-styling), [Style DSL - Advanced States](docs/dsl.md#advanced-states--prefix), and [Methodology](docs/methodology.md#component-architecture-root--sub-elements).
+See [React API - Sub-element Styling](docs/react-api.md#sub-element-styling), [Style DSL - Advanced States](docs/dsl.md#advanced-states--prefix), and [Methodology](docs/methodology.md#component-architecture-root--sub-elements).
 
 ### Style Props
 
@@ -378,7 +382,7 @@ const Space = tasty({
 <Space flow="row" gap={{ '': '2x', '@tablet': '4x' }}>
 ```
 
-See [Runtime API - Style Props](docs/runtime.md#style-props) and [Methodology - styleProps](docs/methodology.md#styleprops-as-the-public-api).
+See [React API - Style Props](docs/react-api.md#style-props) and [Methodology - styleProps](docs/methodology.md#styleprops-as-the-public-api).
 
 ### Mod Props
 
@@ -397,13 +401,13 @@ const Button = tasty({
 <Button isLoading size="lg">Submit</Button>
 ```
 
-See [Runtime API - Mod Props](docs/runtime.md#mod-props) and [Methodology - modProps](docs/methodology.md#modprops-and-mods).
+See [React API - Mod Props](docs/react-api.md#mod-props) and [Methodology - modProps](docs/methodology.md#modprops-and-mods).
 
 ### Variants
 
 Variants let one component expose named visual versions without pre-generating a separate class for every possible combination. In runtime mode, Tasty emits only the variant CSS that is actually used.
 
-See [Runtime API - Variants](docs/runtime.md#variants).
+See [React API - Variants](docs/react-api.md#variants).
 
 ### Recipes
 
@@ -421,17 +425,36 @@ If you prefer explicit control, disable inference with `configure({ autoProperty
 
 See [Style DSL - Properties (`@property`)](docs/dsl.md#properties-property).
 
-### Explicit `@properties`
+### Explicit `@property`
 
-Use explicit `@properties` only when you need to override defaults such as `inherits: false` or a custom `initialValue`.
+Use explicit `@property` only when you need to override defaults such as `inherits: false` or a custom `initialValue`.
 
 See [Style DSL - Properties (`@property`)](docs/dsl.md#properties-property).
 
-### React Hooks
+### CSS Functions (`@function`)
+
+Define reusable, parameterized CSS functions and call them anywhere a value is accepted. Declare with `$$name`, invoke with `$$name(...)`; parameters and local variables use `$name`.
 
-When you do not need a full component wrapper, use the hooks directly: `useStyles` for local class names, `useGlobalStyles` for selector-scoped global CSS, `useRawCSS` for raw rules, plus `useKeyframes` and `useProperty` for animation and custom-property primitives.
+```jsx
+const Card = tasty({
+  styles: {
+    '@function': {
+      $$negative: { args: ['$value'], result: '(-1 * $value)' },
+    },
+    marginTop: '$$negative(2x)',
+  },
+});
+```
 
-See [Runtime API - Hooks](docs/runtime.md#hooks).
+Definitions can also come from `configure({ functions })` or the `useFunction` style function, and work across client, SSR/RSC, and zero-runtime modes. `@function` is an experimental CSS feature, so for browsers that do not ship it yet enable `configure({ polyfills: { functions: true } })` to inline every call into plain CSS at parse time.
+
+See [Style DSL - Functions](docs/dsl.md#functions-function) and [Configuration - Polyfills](docs/configuration.md#polyfills).
+
+### Style Functions
+
+When you do not need a full component wrapper, use the style functions directly: `useStyles` for local class names, `useGlobalStyles` for selector-scoped global CSS, `useRawCSS` for raw rules, plus `useKeyframes`, `useProperty`, `useFontFace`, `useCounterStyle`, and `useFunction` for animation, custom-property, font, counter-style, and CSS-function primitives. All style functions are hook-free and work in React Server Components.
+
+See [React API - Style Functions](docs/react-api.md#style-functions).
 
 ### Zero-Runtime Mode
 
@@ -441,15 +464,19 @@ See [Zero Runtime (tastyStatic)](docs/tasty-static.md) and [Getting Started - Ch
 
 ### `tasty` vs `tastyStatic`
 
-`tasty()` returns React components and injects CSS on demand at runtime. `tastyStatic()` returns class names and extracts CSS during the build. Both share the same DSL, tokens, units, state mappings, and recipes, so the main choice is runtime flexibility versus build-time extraction.
+`tasty()` returns React components that compute CSS during rendering. In server-only contexts, this produces static HTML + CSS with zero client JavaScript — the same end result as `tastyStatic()` but with the full feature set. `tastyStatic()` returns class names and extracts CSS during the build via a Babel plugin, with no React dependency at runtime. Both share the same DSL, tokens, units, state mappings, and recipes. Use `tasty()` as the default for any React-based setup; use `tastyStatic()` when you need build-time extraction without React.
 
-See [Zero Runtime (tastyStatic)](docs/tasty-static.md), [Runtime API](docs/runtime.md), and [Comparison - Build-time vs runtime](docs/comparison.md#build-time-vs-runtime).
+See [Zero Runtime (tastyStatic)](docs/tasty-static.md), [React API](docs/react-api.md), and [Comparison - Build-time vs runtime](docs/comparison.md#build-time-vs-runtime).
 
 ### Server-Side Rendering
 
-SSR layers on top of runtime `tasty()` rather than introducing a separate styling model. Existing components stay unchanged while Tasty collects CSS during server rendering and hydrates the cache on the client.
+`tasty()` components already work on the server without any SSR integration — they are hook-free and render as React Server Components by default. In server-only contexts (Next.js RSC, Astro without islands), they produce zero client JavaScript with the full feature set.
 
-Use `@tenphi/tasty/ssr/next` for Next.js App Router, `@tenphi/tasty/ssr/astro` for Astro, or the core SSR API for other React SSR setups.
+SSR integration (`TastyRegistry`, `tastyIntegration`) adds CSS batching, deduplication across component trees, FOUC prevention, and client cache hydration. Use it when your app also has client-side rendering:
+
+- `@tenphi/tasty/ssr/next` for Next.js App Router (mixed server + client components)
+- `@tenphi/tasty/ssr/astro` for Astro (with or without islands)
+- The core SSR API for other React SSR setups
 
 See the [full SSR guide](docs/ssr.md).
 
@@ -457,15 +484,17 @@ See the [full SSR guide](docs/ssr.md).
 
 | Import | Description | Platform |
 |--------|-------------|----------|
-| `@tenphi/tasty` | Runtime style engine (`tasty`, hooks, `configure`) | Browser |
+| `@tenphi/tasty` | Runtime style engine (`tasty`, style functions, `configure`) | Browser |
 | `@tenphi/tasty/static` | Zero-runtime static styles (`tastyStatic`) | Browser |
+| `@tenphi/tasty/static/inject` | Runtime helper the Babel plugin rewrites `tastyStatic` imports to in inject mode | Browser |
 | `@tenphi/tasty/core` | Lower-level internals (config, parser, pipeline, injector, style handlers) for tooling and advanced use | Browser / Node |
 | `@tenphi/tasty/babel-plugin` | Babel plugin for zero-runtime CSS extraction | Node |
 | `@tenphi/tasty/zero` | Programmatic extraction API | Node |
-| `@tenphi/tasty/next` | Next.js integration wrapper | Node |
+| `@tenphi/tasty/zero/next` | Next.js integration wrapper | Node |
 | `@tenphi/tasty/ssr` | Core SSR API (collector, context, hydration) | Node |
 | `@tenphi/tasty/ssr/next` | Next.js App Router SSR integration | Node |
-| `@tenphi/tasty/ssr/astro` | Astro middleware + auto-hydration | Node / Browser |
+| `@tenphi/tasty/ssr/astro` | Astro integration + middleware | Node |
+| `@tenphi/tasty/ssr/astro-client` | Astro client-side cache hydration | Browser |
 
 ## Browser Requirements
 
@@ -483,39 +512,41 @@ All sizes measured with [size-limit](https://github.com/ai/size-limit) — minif
 
 | Entry point | Size |
 |-------------|------|
-| `@tenphi/tasty` (runtime + SSR) | ~44 kB |
-| `@tenphi/tasty/core` (runtime, no SSR) | ~41 kB |
-| `@tenphi/tasty/static` (zero-runtime) | ~1.5 kB |
+| `@tenphi/tasty` (runtime + SSR) | 50.19 kB |
+| `@tenphi/tasty/core` (runtime, no SSR) | 47.76 kB |
+| `@tenphi/tasty/static` (zero-runtime) | 16.43 kB |
+| `@tenphi/tasty/zero` (programmatic extraction) | 29.6 kB |
+| `@tenphi/tasty/babel-plugin` (Babel plugin entry) | 43.7 kB |
 
-Run `pnpm size` for exact up-to-date numbers.
+Run `pnpm size` to reproduce (outputs may shift slightly with releases).
 
 ### Runtime Benchmarks
 
-If you choose the runtime approach, performance is usually a non-issue in practice. The numbers below show single-call throughput for the core pipeline stages, measured with `vitest bench` on an Apple M1 Max (Node 22).
+If you choose the runtime approach, performance is usually a non-issue in practice. The numbers below show single-call throughput for the core pipeline stages, measured with `pnpm bench` on an Apple M1 Max (Node 22).
 
 | Operation | ops/sec | Latency (mean) |
 |-----------|--------:|---------------:|
-| `renderStyles` — 5 flat properties (cold) | ~72,000 | ~14 us |
-| `renderStyles` — state map with media/hover/modifier (cold) | ~22,000 | ~46 us |
-| `renderStyles` — same styles (cached) | ~7,200,000 | ~0.14 us |
-| `parseStateKey` — simple key like `:hover` (cold) | ~1,200,000 | ~0.9 us |
-| `parseStateKey` — complex OR/AND/NOT key (cold) | ~190,000 | ~5 us |
-| `parseStateKey` — any key (cached) | ~3,300,000–8,900,000 | ~0.1–0.3 us |
-| `parseStyle` — value tokens like `2x 4x` (cold) | ~345,000 | ~3 us |
-| `parseStyle` — color tokens (cold) | ~525,000 | ~1.9 us |
-| `parseStyle` — any value (cached) | ~15,500,000 | ~0.06 us |
+| `renderStyles` — 5 flat properties (cold) | ~60,000 | ~17 us |
+| `renderStyles` — state map with media/hover/modifier (cold) | ~18,500 | ~54 us |
+| `renderStyles` — same styles (cached) | ~5,800,000 | ~0.17 us |
+| `parseStateKey` — simple key like `:hover` (cold) | ~790,000 | ~1.3 us |
+| `parseStateKey` — complex OR/AND/NOT key (cold) | ~140,000 | ~7 us |
+| `parseStateKey` — any key (cached) | ~3,400,000–8,300,000 | ~0.1–0.3 us |
+| `parseStyle` — value tokens like `2x 4x` (cold) | ~344,000 | ~2.9 us |
+| `parseStyle` — color tokens (cold) | ~567,000 | ~1.8 us |
+| `parseStyle` — any value (cached) | ~15,250,000 | ~0.07 us |
 
-"Cold" benchmarks use unique inputs to bypass all caches. Cached benchmarks reuse a single input and measure the LRU hot path.
+"Cold" benchmarks use unique inputs to bypass all caches. Cached benchmarks reuse a single input and measure the LRU hot path. Expect roughly ±10% between runs on an otherwise idle machine.
 
-Run `pnpm bench` to reproduce.
+Run `pnpm bench` to reproduce. `pnpm bench:browser` runs the component-render benchmarks separately, in headless Chromium — those are useful for comparing variants against each other (a plain element vs. one with sub-elements), but the browser's 0.1 ms timer resolution makes their absolute values too coarse to quote. The two suites are deliberately separate commands: running them together lets the browser compete with Node for CPU and depresses both.
 
 #### What This Means in Practice
 
 - **Cached path dominates production.** After a component's first render, subsequent renders with stable styles skip the pipeline entirely (React `useMemo` + LRU cache hits at every level). All cached operations are sub-microsecond — effectively free.
-- **Cold path is fast enough.** The heaviest cold operation — a complex state map with media queries, hover, and modifiers — takes ~46 us. Even a page with 100 unique styled components adds only ~5 ms of total style computation on first render, negligible next to React reconciliation and DOM work.
-- **Cache multipliers are 30x–100x.** This confirms the multi-level LRU architecture (parser, state-key, simplify, condition, pipeline) is delivering real value.
-- **Comparable to lighter systems.** Emotion's `css()` is typically 5–20 us for simple styles; Tasty's cold `renderStyles` at ~14 us for 5 properties is in the same range despite doing significantly more work (state maps, design tokens, sub-elements, chunking).
-- **On slower devices.** The benchmarks above are from an M1 Max (Geekbench 6 SC ~2,400). A mid-range consumer laptop (~1,800 SC) is roughly 1.3x slower; a mid-range phone (~1,200 SC) is roughly 2x slower; a budget phone (~700 SC) is roughly 3–4x slower. Even at 4x, the heaviest cold operation stays under 200 us and 100 unique components under 20 ms — still well within a single frame budget. The cached path remains sub-microsecond on all devices.
+- **Cold path is fast enough.** The heaviest cold operation — a complex state map with media queries, hover, and modifiers — takes ~54 us. Even a page with 100 unique styled components adds only ~5 ms of total style computation on first render, negligible next to React reconciliation and DOM work.
+- **Cache multipliers are 10x–300x.** The parser sees ~30x, state-key parsing ~10x–25x, and the full pipeline ~100x on flat styles and ~300x on complex state maps — the deeper the work, the more the cache saves. This confirms the multi-level LRU architecture (parser, state-key, simplify, condition, pipeline) is delivering real value.
+- **Comparable to lighter systems.** Emotion's `css()` is typically 5–20 us for simple styles; Tasty's cold `renderStyles` at ~17 us for 5 properties is in the same range despite doing significantly more work (state maps, design tokens, sub-elements, chunking).
+- **On slower devices.** The benchmarks above are from an M1 Max (Geekbench 6 SC ~2,400). A mid-range consumer laptop (~1,800 SC) is roughly 1.3x slower; a mid-range phone (~1,200 SC) is roughly 2x slower; a budget phone (~700 SC) is roughly 3–4x slower. Even at 4x, the heaviest cold operation stays under 250 us and 100 unique components under 25 ms — still well within a single frame budget. The cached path remains sub-microsecond on all devices.
 
 ### How It Stays Fast
 
@@ -604,10 +635,16 @@ Start from the docs hub if you want the shortest path to the right guide for you
 
 ### Reference
 
-- **[Style DSL](docs/dsl.md)** — The Tasty style language: state maps, tokens, units, color syntax, extending semantics, recipes, keyframes, and @property
-- **[Runtime API](docs/runtime.md)** — React-specific API: `tasty()` factory, component props, variants, sub-elements, and hooks
-- **[Configuration](docs/configuration.md)** — Global configuration: tokens, recipes, custom units, style handlers, and TypeScript extensions
+- **[Style DSL](docs/dsl.md)** — The Tasty style language: state maps, tokens, units, color syntax, extending semantics, recipes, keyframes, `@property`, `@font-face`, `@counter-style`, and `@function`
+- **[React API](docs/react-api.md)** — React-specific API: `tasty()` factory, component props, variants, sub-elements, and style functions
+- **[Configuration](docs/configuration.md)** — Global configuration: tokens, recipes, custom units, functions, polyfills, style handlers, props middleware, and TypeScript extensions
+- **[Plugins & Extension Points](docs/plugins.md)** — Extending Tasty: choosing an extension point, authoring style handlers and props middleware, and packaging it as a plugin
 - **[Style Properties](docs/styles.md)** — Complete reference for all enhanced style properties: syntax, values, modifiers, and recommendations
+- **[Style Rules for AI Agents](docs/ai-agents.md)** — Condensed, rule-based brief for AI coding agents: correct value syntax, state maps, and property choices in one short page
+
+### Upgrading
+
+- **[Migration Guide (v2 → v3)](docs/migration-v3.md)** — Every breaking change in 3.0 with a search-and-replace cheat sheet: at-rule key renames, the directional-shorthand rule, config keys, renamed and removed exports, and what deliberately did not change
 
 ### Rendering modes
 
@@ -616,7 +653,7 @@ Start from the docs hub if you want the shortest path to the right guide for you
 
 ### Internals
 
-- **[Style rendering pipeline](docs/PIPELINE.md)** — How `Styles` become mutually exclusive CSS rules: parse → exclusives → combinations → handlers → merge → materialize (`src/pipeline/`)
+- **[Style rendering pipeline](docs/pipeline.md)** — How `Styles` become mutually exclusive CSS rules: parse → exclusives → combinations → handlers → merge → materialize (`src/pipeline/`)
 - **[Style Injector](docs/injector.md)** — Internal CSS injection engine: `inject()`, `injectGlobal()`, `injectRawCSS()`, `keyframes()`, deduplication, reference counting, cleanup, SSR support, and Shadow DOM
 - **[Debug Utilities](docs/debug.md)** — Runtime CSS inspection via `tastyDebug`: CSS extraction, element inspection, cache metrics, chunk breakdown, and performance monitoring
 

package/dist/{ssr/async-storage.js → async-storage-DKK-wTD4.js}

@@ -8,27 +8,37 @@ import { AsyncLocalStorage } from "node:async_hooks";
 * The middleware calls runWithCollector() around the render, and
 * useStyles() calls getSSRCollector() to find it.
 *
+* Uses globalThis to ensure the AsyncLocalStorage instance is shared
+* across module instances — frameworks like Astro may load middleware
+* and page components from separate module graphs.
+*
 * This module imports from 'node:async_hooks' — it must be excluded
 * from client bundles via the build configuration.
 */
-const tastySSRStorage = new AsyncLocalStorage();
+const ALS_KEY = "__tasty_ssr_als__";
+function getSharedStorage() {
+	const g = globalThis;
+	if (!g[ALS_KEY]) g[ALS_KEY] = new AsyncLocalStorage();
+	return g[ALS_KEY];
+}
 /**
 * Run a function with a ServerStyleCollector bound to the current
 * async context. All useStyles() calls within `fn` (and any async
 * continuations) will find this collector via getSSRCollector().
 */
 function runWithCollector(collector, fn) {
-	return tastySSRStorage.run(collector, fn);
+	return getSharedStorage().run(collector, fn);
 }
 /**
 * Retrieve the ServerStyleCollector bound to the current async context.
 * Returns null when called outside of runWithCollector() or on the client.
 */
 function getSSRCollector() {
-	if (typeof tastySSRStorage?.getStore !== "function") return null;
-	return tastySSRStorage.getStore() ?? null;
+	const storage = getSharedStorage();
+	if (typeof storage?.getStore !== "function") return null;
+	return storage.getStore() ?? null;
 }
 //#endregion
-export { getSSRCollector, runWithCollector };
+export { runWithCollector as n, getSSRCollector as t };
 
-//# sourceMappingURL=async-storage.js.map
+//# sourceMappingURL=async-storage-DKK-wTD4.js.map

package/dist/async-storage-DKK-wTD4.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"async-storage-DKK-wTD4.js","names":[],"sources":["../src/ssr/async-storage.ts"],"sourcesContent":["/**\n * AsyncLocalStorage integration for SSR collector discovery.\n *\n * Used by Astro middleware and generic framework integrations where\n * the library cannot wrap the React tree with a context provider.\n * The middleware calls runWithCollector() around the render, and\n * useStyles() calls getSSRCollector() to find it.\n *\n * Uses globalThis to ensure the AsyncLocalStorage instance is shared\n * across module instances — frameworks like Astro may load middleware\n * and page components from separate module graphs.\n *\n * This module imports from 'node:async_hooks' — it must be excluded\n * from client bundles via the build configuration.\n */\n\nimport { AsyncLocalStorage } from 'node:async_hooks';\n\nimport type { ServerStyleCollector } from './collector';\n\nconst ALS_KEY = '__tasty_ssr_als__';\n\nfunction getSharedStorage(): AsyncLocalStorage<ServerStyleCollector> {\n  const g = globalThis as Record<string, unknown>;\n  if (!g[ALS_KEY]) {\n    g[ALS_KEY] = new AsyncLocalStorage<ServerStyleCollector>();\n  }\n  return g[ALS_KEY] as AsyncLocalStorage<ServerStyleCollector>;\n}\n\n/**\n * Run a function with a ServerStyleCollector bound to the current\n * async context. All useStyles() calls within `fn` (and any async\n * continuations) will find this collector via getSSRCollector().\n */\nexport function runWithCollector<T>(\n  collector: ServerStyleCollector,\n  fn: () => T,\n): T {\n  return getSharedStorage().run(collector, fn);\n}\n\n/**\n * Retrieve the ServerStyleCollector bound to the current async context.\n * Returns null when called outside of runWithCollector() or on the client.\n */\nexport function getSSRCollector(): ServerStyleCollector | null {\n  const storage = getSharedStorage();\n  if (typeof storage?.getStore !== 'function') return null;\n  return storage.getStore() ?? null;\n}\n"],"mappings":";;;;;;;;;;;;;;;;;AAoBA,MAAM,UAAU;AAEhB,SAAS,mBAA4D;CACnE,MAAM,IAAI;CACV,IAAI,CAAC,EAAE,UACL,EAAE,WAAW,IAAI,kBAAwC;CAE3D,OAAO,EAAE;AACX;;;;;;AAOA,SAAgB,iBACd,WACA,IACG;CACH,OAAO,iBAAiB,CAAC,CAAC,IAAI,WAAW,EAAE;AAC7C;;;;;AAMA,SAAgB,kBAA+C;CAC7D,MAAM,UAAU,iBAAiB;CACjC,IAAI,OAAO,SAAS,aAAa,YAAY,OAAO;CACpD,OAAO,QAAQ,SAAS,KAAK;AAC/B"}

package/dist/babel-R2qT7yLN.d.ts

@@ -0,0 +1,83 @@
+import { t as TastyConfig } from "./config-De8L9NWM.js";
+import { PluginPass } from "@babel/core";
+
+//#region src/zero/babel-types.d.ts
+/**
+ * Build-time configuration for zero-runtime mode.
+ * Subset of TastyConfig excluding runtime-only DOM options
+ * (`nonce`, `maxRulesPerSheet`, `forceTextInjection`, `gc`)
+ * and overriding `devMode` default to `false`.
+ */
+type TastyZeroConfig = Omit<TastyConfig, 'nonce' | 'maxRulesPerSheet' | 'forceTextInjection' | 'gc' | 'devMode'> & {
+  /**
+   * Enable development mode features: source comments in generated CSS.
+   * @default false
+   */
+  devMode?: boolean;
+};
+//#endregion
+//#region src/zero/babel.d.ts
+/**
+ * Options for the `@tenphi/tasty/babel-plugin` Babel plugin.
+ */
+interface TastyZeroBabelOptions {
+  /** Output path for generated CSS (default: 'tasty.css') */
+  output?: string;
+  /**
+   * Tasty configuration for build-time processing.
+   * Can be a static object or a factory function that returns fresh config.
+   * A factory is called on each plugin invocation, enabling hot reload
+   * of config values that depend on external files (e.g. theme tokens).
+   */
+  config?: TastyZeroConfig | (() => TastyZeroConfig);
+  /**
+   * Absolute path to a TypeScript/JavaScript module that default-exports
+   * a `TastyZeroConfig` object. The module is loaded via jiti on each
+   * plugin invocation, enabling hot reload when the file changes.
+   *
+   * This option is JSON-serializable and is the primary way Turbopack
+   * passes config to the Babel plugin (since Turbopack loader options
+   * must be plain primitives/objects/arrays).
+   *
+   * When both `config` and `configFile` are set, `config` takes precedence.
+   *
+   * @example '/absolute/path/to/tasty-zero.config.ts'
+   */
+  configFile?: string;
+  /**
+   * Absolute file paths whose content affects the generated CSS.
+   * When any of these files change, babel-loader invalidates its cache
+   * and re-runs the plugin with fresh config values.
+   *
+   * Typically includes theme files that define Glaze palettes or token values.
+   * Paths must be absolute (resolved by the Next.js wrapper).
+   */
+  configDeps?: string[];
+  /**
+   * Automatically replace `@tenphi/tasty/static` imports with an import
+   * of the generated CSS file. This eliminates the need for users to
+   * manually import the CSS in their app entry point.
+   *
+   * @default true
+   */
+  injectImport?: boolean;
+  /**
+   * Output mode for extracted CSS.
+   *
+   * - `'file'` (default): CSS is written to a single output file and
+   *   the `@tenphi/tasty/static` import is rewritten to import that file.
+   * - `'inject'`: CSS is embedded inline in the JS output and injected
+   *   at runtime via a tiny injector from `@tenphi/tasty/static/inject`.
+   *   No CSS file is written. Each `tastyStatic` call becomes
+   *   self-contained. Best for reusable components and extensions.
+   *
+   * When `mode` is `'inject'`, `output` and `injectImport` are ignored.
+   *
+   * @default 'file'
+   */
+  mode?: 'file' | 'inject';
+}
+declare const _default: (api: object, options: TastyZeroBabelOptions | null | undefined, dirname: string) => import("@babel/core").PluginObj<PluginPass>;
+//#endregion
+export { _default as n, TastyZeroConfig as r, TastyZeroBabelOptions as t };
+//# sourceMappingURL=babel-R2qT7yLN.d.ts.map