@bamboocss/types 1.34.0 → 1.35.0

package/dist/config.d.ts

@@ -407,34 +407,6 @@ interface CodegenOptions {
    * @default 'true'
    */
   shorthands?: boolean
-  /**
-   * Whether a lowered style leaf falls back to `css()` for a value that is not a scalar.
-   *
-   * Only the build-time fold calls the helper this governs. `css({ color: tone })` lowers to
-   * `cssLeaf('c_', 'color', tone)`, which builds the class by concatenation — and hands the
-   * value to `css()` when it turns out to be a condition object or a responsive array, which
-   * no concatenation describes.
-   *
-   * That fallback is the single edge keeping the css engine in a bundle. It is reachable only
-   * for a value the fold could not see the shape of, and it costs the whole prize: on
-   * `sandbox/runtime-perf`, one dynamic leaf takes a module from **923 B to 7,542 B gzipped**,
-   * because the reference pulls in `createCss`, the merge, the utility and shorthand tables
-   * and the conditions. Turned off, the same module keeps 10 top-level bindings instead of 39.
-   *
-   * Turning it off asserts something about your source: **a style value that varies at runtime
-   * is a scalar** — a string, a number, a boolean, or nothing. Write conditions and responsive
-   * values as literals at the call site, where the fold reads them and resolves each branch,
-   * rather than assembling them into a variable. A value that breaks the assertion throws,
-   * naming the property, instead of silently producing a class with no rule behind it.
-   *
-   * Pairs with `failOnUnfolded` in `@bamboocss/vite`: with the fallback off a lowered leaf no
-   * longer keeps the engine, so that option stops reporting one as a survivor. Together they
-   * are what makes zero runtime reachable for an app that has any dynamic styling at all —
-   * before this, it required an app with none.
-   *
-   * @default true
-   */
-  leafFallback?: boolean
   /**
    * File extension for generated javascript files.
    * @default 'mjs'

package/dist/parser.d.ts

@@ -11,7 +11,17 @@ export interface ResultItem {
    * Both live in `ParserResult.token`, since every consumer that reads a token *path* out of
    * a result wants both.
    */
-  type?: 'css' | 'cva' | 'sva' | 'token' | 'tokenValue' | 'pattern' | 'recipe' | 'jsx-recipe' | 'cva-call'
+  type?:
+    | 'css'
+    | 'cva'
+    | 'sva'
+    | 'token'
+    | 'tokenValue'
+    | 'viewTransition'
+    | 'pattern'
+    | 'recipe'
+    | 'jsx-recipe'
+    | 'cva-call'
   box?: BoxNodeMap | BoxNodeLiteral | BoxNodeArray
   /**
    * For a `cva-call`, the module the recipe was declared in when that is not this one.

package/dist/recipe.d.ts

@@ -64,17 +64,13 @@ export interface RecipeDefinition<T extends RecipeVariantRecord = RecipeVariantR
    */
   base?: SystemStyleObject
   /**
-   * The prefix every class this recipe emits is built from — `button` gives `button` for
-   * the base styles and `button--size_sm` for a variant.
+   * Semantic recipe name used by extraction-only integrations.
    *
    * Required for a recipe declared in `theme.recipes`, where it is the key it is declared
-   * under. Optional for an inline `cva`, which is otherwise named by hashing its own
-   * config: `cva_a1b2c3--size_sm`. Setting it buys readable class names and nothing else —
-   * the CSS is identical either way.
+   * under. Optional for an inline `cva`.
    *
-   * It has to be unique across every recipe in the build. Two recipes sharing a name emit
-   * rules under the same selectors, and the later one wins for any variant they both
-   * declare.
+   * The Vite compiler ignores this field when allocating declaration atoms: recipe identity
+   * is not style identity, so identical declarations share one class across recipes.
    */
   className?: string
   /**
@@ -117,7 +113,10 @@ interface RecipeConfigMeta {
 
 export interface RecipeConfig<T extends RecipeVariantRecord = RecipeVariantRecord>
   extends RecipeDefinition<T>, RecipeConfigMeta {
-  /** Optional on `RecipeDefinition`, where an inline `cva` falls back to hashing its config. A recipe declared in `theme.recipes` always has one — the key it is declared under. */
+  /**
+   * Required extraction metadata for a configured recipe: the key under which it is
+   * declared in `theme.recipes`. The Vite compiler does not use it as style identity.
+   */
   className: string
 }
 
@@ -169,16 +168,13 @@ export interface SlotRecipeDefinition<
   T extends SlotRecipeVariantRecord<S> = SlotRecipeVariantRecord<S>,
 > {
   /**
-   * The prefix every class this recipe emits is built from, and the name to target its
-   * slots in the DOM by — `checkbox` gives `checkbox__control` for a slot and
-   * `checkbox__control--size_md` for that slot under a variant.
+   * Semantic recipe name used by extraction-only integrations.
    *
    * Required for a recipe declared in `theme.slotRecipes`, where it is the key it is
-   * declared under. Optional for an inline `sva`, which is otherwise named by hashing its
-   * own config. Setting it buys readable class names and nothing else — the CSS is
-   * identical either way.
+   * declared under. Optional for an inline `sva`.
    *
-   * It has to be unique across every recipe in the build.
+   * The Vite compiler ignores this field when allocating declaration atoms: recipe and slot
+   * identity do not enter generated class names.
    */
   className?: string
   /**
@@ -190,9 +186,10 @@ export interface SlotRecipeDefinition<
    */
   slots: S[] | Readonly<S[]>
   /**
-   * The slots that enclose other slots, used to scope their variant styles.
+   * The slots that enclose other slots in extraction-only named-rule output.
    *
-   * A slot recipe's variants are chosen once, at the top, but the slots that react to them
+   * The Vite compiler returns selected atoms directly for every slot and ignores this field.
+   * In extraction-only output, a slot recipe's variants are chosen once at the top, but the slots that react to them
    * are authored by the consumer somewhere below. Naming the enclosing slots lets the build
    * emit their variant styles as rules scoped by a class those slots already carry, so
    * nothing has to be delivered to a slot at runtime and every other slot's class is a
@@ -247,6 +244,9 @@ export type SlotRecipeConfig<
   T extends SlotRecipeVariantRecord<S> = SlotRecipeVariantRecord<S>,
 > = SlotRecipeDefinition<S, T> &
   RecipeConfigMeta & {
-    /** Optional on `SlotRecipeDefinition`, where an inline `sva` falls back to hashing its config. A recipe declared in `theme.slotRecipes` always has one — the key it is declared under. */
+    /**
+     * Required extraction metadata for a configured recipe: the key under which it is
+     * declared in `theme.slotRecipes`. The Vite compiler does not use it as style identity.
+     */
     className: string
   }

package/dist/reporter.d.ts

@@ -1,6 +1,6 @@
 import type { ParserResultInterface } from './parser'
 
-export type ReportItemType = 'css' | 'cva' | 'sva' | 'token' | 'pattern' | 'recipe' | 'jsx-recipe'
+export type ReportItemType = 'css' | 'cva' | 'sva' | 'token' | 'viewTransition' | 'pattern' | 'recipe' | 'jsx-recipe'
 
 type ComponentKind = 'component' | 'function'
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bamboocss/types",
-  "version": "1.34.0",
+  "version": "1.35.0",
   "description": "The types for css bamboo",
   "homepage": "https://bamboocss.com",
   "license": "MIT",
@@ -32,7 +32,7 @@
     "ncp": "2.0.0",
     "pkg-types": "2.3.0",
     "ts-morph": "28.0.0",
-    "@bamboocss/extractor": "1.34.0"
+    "@bamboocss/extractor": "1.35.0"
   },
   "scripts": {
     "dev": "tsx scripts/watch.ts",