@bamboocss/vite 1.34.1 → 1.35.0

package/dist/index.d.cts

@@ -1,9 +1,8 @@
 import { Plugin } from "vite";
-import { Context } from "@bamboocss/core";
-import { Dict, ParserResultInterface, ResultItem } from "@bamboocss/types";
-import MagicString from "magic-string";
-import { SourceFile } from "ts-morph";
 
+//#region src/static-session.d.ts
+type DenseClassNameMode = boolean | 'stable' | 'local';
+//#endregion
 //#region src/css.d.ts
 /**
  * What a project imports to get the stylesheet.
@@ -13,257 +12,21 @@ import { SourceFile } from "ts-morph";
  * bundled as javascript and injected as a script.
  */
 declare const VIRTUAL_CSS_ID = "virtual:bamboo.css";
-interface BambooCssPluginOptions {
-  configPath?: string;
-  cwd?: string;
-}
-/**
- * Serve bamboo's stylesheet as a virtual module, in dev and in build.
- *
- * This is the integration itself, not an optimisation: without it nothing emits css and
- * the generated `styled-system` runtime names classes no rule exists for.
- *
- * A virtual module rather than a file written to disk, because vite already owns the two
- * things a file would have to reimplement. In dev it injects css over the websocket and
- * replaces it in place, so an edit repaints without reloading; in build it hashes the
- * content into the asset graph and lets the bundler decide where it lands. Writing
- * `styles.css` and asking the project to import it means the build reads a file the same
- * process just wrote, which is a race on any watch rebuild.
- */
-declare const bamboocssCss: (options?: BambooCssPluginOptions) => Plugin;
-//#endregion
-//#region src/fold-recipe.d.ts
-/**
- * Lowering a call of an inline recipe to the class string it produces.
- *
- * The prize is not the `cva` runtime, which is small. It is the *config*: `cva({ base, variants })`
- * ships the whole style object to the browser purely so the runtime can hash it into a name and
- * pick classes off it. Those styles are already in the stylesheet. Once every call of a binding
- * is lowered, the binding is unreferenced and a bundler drops the config with it — measured at
- * 81 kB gzipped across one application's 1,297 inline recipes, against 4.5 kB for the runtime.
- *
- * Correct by construction rather than by a matching reimplementation: the class names come from
- * `getRecipeIdentity` and `getRecipeClassNames`, the same functions the browser runs, and the
- * prefixing and hashing from `classFormatter`, which is what the encoder emitted rules under.
- */
-type Dict$1 = Record<string, unknown>;
-/** A recipe's config, as the extractor resolved it. */
-interface RecipeConfig {
-  className?: string;
-  base?: Dict$1;
-  variants?: Record<string, Record<string, unknown>>;
-  defaultVariants?: Record<string, unknown>;
-  compoundVariants?: unknown[];
-  /** Present on a slot recipe, which resolves to one class per slot rather than a string. */
-  slots?: unknown;
-}
-/**
- * A recipe the fold can lower against.
- *
- * `name` is hashed once here rather than per call site: `getRecipeIdentity` serialises the
- * whole config to hash it, which measured as 91% of the per-call work when it sat inside
- * `lowerRecipeCall`. The runtime does it once per `cva()` for the same reason.
- *
- * `box` is the *definition's* node, carried so the fold can register the module the config
- * came from as a watch dependency. Without it, editing a config in another module leaves
- * every literal folded against it stale — the stylesheet gets a new identity and the element
- * keeps the old class.
- */
-interface RecipeEntry {
-  config: RecipeConfig;
-  name: string;
-  box: ResultItem['box'];
-}
-//#endregion
-//#region src/runtime-css.d.ts
-/**
- * The generated runtime's `css`, rebuilt in-process from a resolved context.
- *
- * A fold replaces a call with the string the runtime would have returned, so it has
- * to compute that string the same way the runtime does — not the way the stylesheet
- * does. The two differ in one respect that matters here: `StyleDecoder` escapes class
- * names for use in a CSS selector (`.c_red\.300`), while the runtime emits the raw
- * value that belongs in a `class` attribute (`c_red.300`). Folding the decoder's form
- * would put a stray backslash in the DOM.
- *
- * Matching the runtime this way makes the substitution behaviour-preserving by
- * construction. What still needs asserting — and is asserted in `__tests__` — is that
- * these class names correspond to rules the build actually emits.
- *
- * Mirrors `generateCssFn` in `@bamboocss/generator`: `css = memo((...styles) =>
- * cssFn(mergeCssUncached(...styles)))`, with the memo on the argument list and neither
- * inner cache. Unlike the generated runtime this one is built once per build and shared
- * across every module, so the outer cache is what carries the repeats.
- */
-interface RuntimeCss {
-  (...styles: Dict[]): string;
-}
-declare const createRuntimeCss: (ctx: Context) => RuntimeCss;
-//#endregion
-//#region src/fold.d.ts
-/**
- * Why a call site was left alone. Surfaced through `panda`-style diagnostics so a
- * user can tell the difference between "this folded" and "this silently didn't".
- */
-type SkipReason = 'dynamic' | 'raw-call' | 'not-foldable' | 'recipe-call' | 'unsupported-kind' | 'not-imported' | 'no-call-expression' | 'overlapping' | 'empty' | 'unresolved-token' | 'runtime-binding' | 'fold-failed';
-interface FoldedCall {
-  name: string;
-  /**
-   * What the call collapsed to.
-   *
-   * `class` is every style surface: a class string bound for a `class` attribute. `value`
-   * is `token()`, which resolves to a CSS *value* (`var(--colors-red-300)`). The two are
-   * not interchangeable, and a consumer that checks folded classes against the emitted
-   * stylesheet has to skip the latter — there is no rule named after a variable reference.
-   */
-  kind: 'class' | 'value';
-  /** The class string resolved outright, empty when the whole call lowered to ternaries. */
-  className: string;
-  /**
-   * Every class literal the replacement emits, including both arms of each ternary — so a
-   * consumer checking that folded classes have CSS behind them sees the branches too,
-   * which `className` alone does not carry.
-   */
-  classNames: string[];
-  /** The literal written in place of the call, for a `value` fold. */
-  value?: string;
-  start: number;
-  end: number;
-}
-interface SkippedCall {
-  name: string;
-  reason: SkipReason;
-  start: number;
-  end: number;
-}
-interface FoldResult {
-  code: string;
-  /** Null when nothing was folded, so callers can return the original module untouched. */
-  map: ReturnType<MagicString['generateMap']> | null;
-  folded: FoldedCall[];
-  skipped: SkippedCall[];
-  /**
-   * Other modules a folded value came from.
-   *
-   * The extractor resolves values across files, so `css(importedStyles, { … })` folds
-   * to a string that depends on a file this module only imports. Without registering
-   * that edge, editing the imported module leaves a stale literal behind in every
-   * consumer. Bundlers need these as watch files.
-   */
-  dependencies: string[];
-}
-interface FoldOptions {
-  ctx: Context;
-  code: string;
-  parserResult: ParserResultInterface;
-  filePath: string;
-  /** Reuse one runtime `css` across files in a build. */
-  runtimeCss?: RuntimeCss;
-  /**
-   * Split a `css()` call that is only partly static, keeping the dynamic half at runtime.
-   * On by default.
-   */
-  partial?: boolean;
-  /**
-   * Parse another module, for a recipe whose `cva` config lives outside this one.
-   *
-   * Threaded in rather than read off `ctx`, because the project belongs to the node
-   * context and this signature takes the core one. Its absence is a supported state:
-   * without it a cross-module recipe call is still *reported*, which is the half that
-   * used to be missing entirely — it simply cannot be lowered.
-   *
-   * Pulling the module on demand is also what makes the fold order-independent. A
-   * bundler transforms a consumer before the module it imports, so a registry built
-   * from what has been transformed so far would fold or decline the same file
-   * depending on discovery order.
-   */
-  parseModule?: (filePath: string) => ParserResultInterface | undefined;
-  /**
-   * Configs of modules other than this one, shared across a build.
-   *
-   * Owned by the caller because it has to outlive one call: the declaring module would
-   * otherwise be re-parsed once per module that imports it, which is `consumers x module
-   * size` on the transform path — measured at 909ms against 8.3ms for fifty consumers of a
-   * hundred-recipe module. The caller clears an entry when the file changes, which is the
-   * only place that knows.
-   */
-  recipeConfigCache?: Map<string, ForeignRecipes>;
-  /**
-   * Also report bamboo bindings the rewrite left behind, whatever the skip ledger says.
-   *
-   * The ledger holds only calls something recognised, so it answers "of the calls I looked
-   * at, which survived" — and a guarantee built on it is worth exactly what the recogniser
-   * is. A cross-module recipe call used to appear in neither column, so a build could report
-   * a clean sweep while shipping hundreds of them.
-   *
-   * This asks what the guarantee actually claims: after the rewrite, is anything from a
-   * bamboo module still referenced? Off by default because it costs an identifier walk, and
-   * only `failOnUnfolded` needs an answer it can fail a build on.
-   */
-  reportSurvivors?: boolean;
-  /**
-   * The module's own AST, when the caller already holds it.
-   *
-   * Only `reportSurvivors` needs it, and only for the case it exists to catch: a module whose
-   * bamboo usage produced no parser result at all has no call to reach the AST through.
-   */
-  sourceFile?: SourceFile;
-}
-/**
- * What one foreign module contributes, in a form that outlives it.
- *
- * Plain data only. Anything holding a ts-morph node would be read after the next
- * `addSourceFile` forgets that module's tree.
- */
-interface ForeignRecipes {
-  configs: Map<string, RecipeEntry>;
-  /** How that module spelled the css module, for a helper import written into a consumer. */
-  cssSpecifier?: string;
-}
-declare const foldSource: (options: FoldOptions) => FoldResult;
 //#endregion
 //#region src/plugin.d.ts
 interface BambooVitePluginOptions {
-  /**
-   * Rewrite statically-resolvable `css()` and pattern calls into literal class
-   * strings, so they cost nothing at runtime.
-   *
-   * On by default, and build-only — it never runs in `vite dev`, where the parse would land
-   * on every hot update and a dev bundle gains nothing from pre-resolved calls.
-   *
-   * What it buys is per-call CPU, not bytes: the runtime still ships, because dropping it
-   * needs *every* call site in the graph to fold. Bundle size moves slightly against you —
-   * measured at -0.8% raw and +1.0% gzipped on `sandbox/runtime-perf`, since distinct class
-   * literals compress worse than the repeated `css({ … })` calls they replace. Set it to
-   * `false` if that trade is the wrong way round for you, or to keep builds faster: folding
-   * re-parses each module with `ts-morph`, roughly 0.3ms for a small component and 3ms for a
-   * 147-line file with 24 call sites.
-   *
-   * @default true
-   */
-  transform?: boolean;
-  /**
-   * Split a call or element that is only partly static, so the resolvable half becomes a
-   * literal and only the rest keeps its runtime call. On by default.
-   *
-   * Without it a single dynamic value declines the whole site.
-   *
-   * @default true
-   */
-  partial?: boolean;
   /** Path to `bamboo.config.ts`. Resolved the same way the CLI resolves it. */
   configPath?: string;
   cwd?: string;
   /**
-   * Report every call site that did *not* fold, and why, per file. Useful when a call
-   * you expected to collapse still shows up in the bundle.
+   * Report every call site the compiler rejected, and why, per file.
    *
    * @default false
    */
   reportSkipped?: boolean;
   /**
-   * Print a coverage summary when the build finishes: how much folded, and what the
-   * remainder was declined for.
+   * Print a coverage summary when the build finishes: how much compiled, and why any
+   * candidates were rejected.
    *
    * On by default. Without it there is no signal that the transform did anything, and
    * no way to tell a project where everything folds from one where nothing does.
@@ -272,38 +35,30 @@ interface BambooVitePluginOptions {
    */
   reportSummary?: boolean;
   /**
-   * Fail the build when a `css()` or pattern call is left for the runtime.
-   *
-   * The fold's value is not the per-call CPU it saves — it is that a bundle where *every*
-   * such call folded no longer imports `styled-system/css` at all, and the engine behind it
-   * drops out. One survivor keeps the whole thing, so a coverage percentage cannot tell you
-   * whether you got the prize. This can.
-   *
-   * Deliberately silent about `cva`/`sva`. A `cva(...)` definition returns a function and can
-   * never collapse to a class string, so failing on it would make this unusable for anyone
-   * writing recipes — and recipes keep their own much smaller runtime by design. What this
-   * guarantees is narrower and checkable: nothing still calls `css()`.
-   *
-   * Named for what it checks. It was `strict`, which meant nothing in common with
-   * `strictTokens` or a pattern's old `strict` — three unrelated options sharing a word, to
-   * the point that comments in this repo used a bare "strict" for all three.
-   *
-   * @default false
+   * Compact atom names. `true`/`stable` is deterministic across
+   * client and SSR builds. `local` uses the shortest names and is safe only when one build
+   * produces both HTML and CSS. @default true
+   */
+  denseClassNames?: DenseClassNameMode;
+  /**
+   * Maximum complete selections compiled for one runtime `cva`/`sva` call. This bounds
+   * build time and memory for the exact compound-variant decision table. @default 65536
    */
-  failOnUnfolded?: boolean;
+  maxRecipeStates?: number;
 }
 /**
  * Vite integration for Bamboo CSS.
  *
  * Two plugins, because they do unrelated jobs on different schedules. The first emits the
  * stylesheet as a virtual module and runs in dev and build alike — that is the integration,
- * and nothing styles without it. The second is the optional build-time fold.
+ * and nothing styles without it. The second compiles every Bamboo source call in both dev
+ * and build; there is no runtime styling fallback.
  *
- * The fold runs with `enforce: 'pre'` so it sees module source as close as possible to what
+ * The compiler runs with `enforce: 'pre'` so it sees module source as close as possible to what
  * the CSS extractor reads off disk. A plugin that rewrites style calls before bamboo
  * sees them would otherwise make the two disagree, and a folded class could end up
  * with no matching rule.
  */
 declare const bamboocss: (options?: BambooVitePluginOptions) => Plugin[];
 //#endregion
-export { type BambooCssPluginOptions, type BambooVitePluginOptions, type FoldOptions, type FoldResult, type FoldedCall, type RuntimeCss, type SkipReason, type SkippedCall, VIRTUAL_CSS_ID, bamboocss, bamboocss as default, bamboocssCss, createRuntimeCss, foldSource };
+export { type BambooVitePluginOptions, VIRTUAL_CSS_ID, bamboocss, bamboocss as default };

package/dist/index.d.mts

@@ -1,9 +1,8 @@
-import MagicString from "magic-string";
-import { Node, SourceFile } from "ts-morph";
-import { Context } from "@bamboocss/core";
 import { Plugin } from "vite";
-import { Dict, ParserResultInterface, ResultItem } from "@bamboocss/types";
 
+//#region src/static-session.d.ts
+type DenseClassNameMode = boolean | 'stable' | 'local';
+//#endregion
 //#region src/css.d.ts
 /**
  * What a project imports to get the stylesheet.
@@ -13,257 +12,21 @@ import { Dict, ParserResultInterface, ResultItem } from "@bamboocss/types";
  * bundled as javascript and injected as a script.
  */
 declare const VIRTUAL_CSS_ID = "virtual:bamboo.css";
-interface BambooCssPluginOptions {
-  configPath?: string;
-  cwd?: string;
-}
-/**
- * Serve bamboo's stylesheet as a virtual module, in dev and in build.
- *
- * This is the integration itself, not an optimisation: without it nothing emits css and
- * the generated `styled-system` runtime names classes no rule exists for.
- *
- * A virtual module rather than a file written to disk, because vite already owns the two
- * things a file would have to reimplement. In dev it injects css over the websocket and
- * replaces it in place, so an edit repaints without reloading; in build it hashes the
- * content into the asset graph and lets the bundler decide where it lands. Writing
- * `styles.css` and asking the project to import it means the build reads a file the same
- * process just wrote, which is a race on any watch rebuild.
- */
-declare const bamboocssCss: (options?: BambooCssPluginOptions) => Plugin;
-//#endregion
-//#region src/fold-recipe.d.ts
-/**
- * Lowering a call of an inline recipe to the class string it produces.
- *
- * The prize is not the `cva` runtime, which is small. It is the *config*: `cva({ base, variants })`
- * ships the whole style object to the browser purely so the runtime can hash it into a name and
- * pick classes off it. Those styles are already in the stylesheet. Once every call of a binding
- * is lowered, the binding is unreferenced and a bundler drops the config with it — measured at
- * 81 kB gzipped across one application's 1,297 inline recipes, against 4.5 kB for the runtime.
- *
- * Correct by construction rather than by a matching reimplementation: the class names come from
- * `getRecipeIdentity` and `getRecipeClassNames`, the same functions the browser runs, and the
- * prefixing and hashing from `classFormatter`, which is what the encoder emitted rules under.
- */
-type Dict$1 = Record<string, unknown>;
-/** A recipe's config, as the extractor resolved it. */
-interface RecipeConfig {
-  className?: string;
-  base?: Dict$1;
-  variants?: Record<string, Record<string, unknown>>;
-  defaultVariants?: Record<string, unknown>;
-  compoundVariants?: unknown[];
-  /** Present on a slot recipe, which resolves to one class per slot rather than a string. */
-  slots?: unknown;
-}
-/**
- * A recipe the fold can lower against.
- *
- * `name` is hashed once here rather than per call site: `getRecipeIdentity` serialises the
- * whole config to hash it, which measured as 91% of the per-call work when it sat inside
- * `lowerRecipeCall`. The runtime does it once per `cva()` for the same reason.
- *
- * `box` is the *definition's* node, carried so the fold can register the module the config
- * came from as a watch dependency. Without it, editing a config in another module leaves
- * every literal folded against it stale — the stylesheet gets a new identity and the element
- * keeps the old class.
- */
-interface RecipeEntry {
-  config: RecipeConfig;
-  name: string;
-  box: ResultItem['box'];
-}
-//#endregion
-//#region src/runtime-css.d.ts
-/**
- * The generated runtime's `css`, rebuilt in-process from a resolved context.
- *
- * A fold replaces a call with the string the runtime would have returned, so it has
- * to compute that string the same way the runtime does — not the way the stylesheet
- * does. The two differ in one respect that matters here: `StyleDecoder` escapes class
- * names for use in a CSS selector (`.c_red\.300`), while the runtime emits the raw
- * value that belongs in a `class` attribute (`c_red.300`). Folding the decoder's form
- * would put a stray backslash in the DOM.
- *
- * Matching the runtime this way makes the substitution behaviour-preserving by
- * construction. What still needs asserting — and is asserted in `__tests__` — is that
- * these class names correspond to rules the build actually emits.
- *
- * Mirrors `generateCssFn` in `@bamboocss/generator`: `css = memo((...styles) =>
- * cssFn(mergeCssUncached(...styles)))`, with the memo on the argument list and neither
- * inner cache. Unlike the generated runtime this one is built once per build and shared
- * across every module, so the outer cache is what carries the repeats.
- */
-interface RuntimeCss {
-  (...styles: Dict[]): string;
-}
-declare const createRuntimeCss: (ctx: Context) => RuntimeCss;
-//#endregion
-//#region src/fold.d.ts
-/**
- * Why a call site was left alone. Surfaced through `panda`-style diagnostics so a
- * user can tell the difference between "this folded" and "this silently didn't".
- */
-type SkipReason = 'dynamic' | 'raw-call' | 'not-foldable' | 'recipe-call' | 'unsupported-kind' | 'not-imported' | 'no-call-expression' | 'overlapping' | 'empty' | 'unresolved-token' | 'runtime-binding' | 'fold-failed';
-interface FoldedCall {
-  name: string;
-  /**
-   * What the call collapsed to.
-   *
-   * `class` is every style surface: a class string bound for a `class` attribute. `value`
-   * is `token()`, which resolves to a CSS *value* (`var(--colors-red-300)`). The two are
-   * not interchangeable, and a consumer that checks folded classes against the emitted
-   * stylesheet has to skip the latter — there is no rule named after a variable reference.
-   */
-  kind: 'class' | 'value';
-  /** The class string resolved outright, empty when the whole call lowered to ternaries. */
-  className: string;
-  /**
-   * Every class literal the replacement emits, including both arms of each ternary — so a
-   * consumer checking that folded classes have CSS behind them sees the branches too,
-   * which `className` alone does not carry.
-   */
-  classNames: string[];
-  /** The literal written in place of the call, for a `value` fold. */
-  value?: string;
-  start: number;
-  end: number;
-}
-interface SkippedCall {
-  name: string;
-  reason: SkipReason;
-  start: number;
-  end: number;
-}
-interface FoldResult {
-  code: string;
-  /** Null when nothing was folded, so callers can return the original module untouched. */
-  map: ReturnType<MagicString['generateMap']> | null;
-  folded: FoldedCall[];
-  skipped: SkippedCall[];
-  /**
-   * Other modules a folded value came from.
-   *
-   * The extractor resolves values across files, so `css(importedStyles, { … })` folds
-   * to a string that depends on a file this module only imports. Without registering
-   * that edge, editing the imported module leaves a stale literal behind in every
-   * consumer. Bundlers need these as watch files.
-   */
-  dependencies: string[];
-}
-interface FoldOptions {
-  ctx: Context;
-  code: string;
-  parserResult: ParserResultInterface;
-  filePath: string;
-  /** Reuse one runtime `css` across files in a build. */
-  runtimeCss?: RuntimeCss;
-  /**
-   * Split a `css()` call that is only partly static, keeping the dynamic half at runtime.
-   * On by default.
-   */
-  partial?: boolean;
-  /**
-   * Parse another module, for a recipe whose `cva` config lives outside this one.
-   *
-   * Threaded in rather than read off `ctx`, because the project belongs to the node
-   * context and this signature takes the core one. Its absence is a supported state:
-   * without it a cross-module recipe call is still *reported*, which is the half that
-   * used to be missing entirely — it simply cannot be lowered.
-   *
-   * Pulling the module on demand is also what makes the fold order-independent. A
-   * bundler transforms a consumer before the module it imports, so a registry built
-   * from what has been transformed so far would fold or decline the same file
-   * depending on discovery order.
-   */
-  parseModule?: (filePath: string) => ParserResultInterface | undefined;
-  /**
-   * Configs of modules other than this one, shared across a build.
-   *
-   * Owned by the caller because it has to outlive one call: the declaring module would
-   * otherwise be re-parsed once per module that imports it, which is `consumers x module
-   * size` on the transform path — measured at 909ms against 8.3ms for fifty consumers of a
-   * hundred-recipe module. The caller clears an entry when the file changes, which is the
-   * only place that knows.
-   */
-  recipeConfigCache?: Map<string, ForeignRecipes>;
-  /**
-   * Also report bamboo bindings the rewrite left behind, whatever the skip ledger says.
-   *
-   * The ledger holds only calls something recognised, so it answers "of the calls I looked
-   * at, which survived" — and a guarantee built on it is worth exactly what the recogniser
-   * is. A cross-module recipe call used to appear in neither column, so a build could report
-   * a clean sweep while shipping hundreds of them.
-   *
-   * This asks what the guarantee actually claims: after the rewrite, is anything from a
-   * bamboo module still referenced? Off by default because it costs an identifier walk, and
-   * only `failOnUnfolded` needs an answer it can fail a build on.
-   */
-  reportSurvivors?: boolean;
-  /**
-   * The module's own AST, when the caller already holds it.
-   *
-   * Only `reportSurvivors` needs it, and only for the case it exists to catch: a module whose
-   * bamboo usage produced no parser result at all has no call to reach the AST through.
-   */
-  sourceFile?: SourceFile;
-}
-/**
- * What one foreign module contributes, in a form that outlives it.
- *
- * Plain data only. Anything holding a ts-morph node would be read after the next
- * `addSourceFile` forgets that module's tree.
- */
-interface ForeignRecipes {
-  configs: Map<string, RecipeEntry>;
-  /** How that module spelled the css module, for a helper import written into a consumer. */
-  cssSpecifier?: string;
-}
-declare const foldSource: (options: FoldOptions) => FoldResult;
 //#endregion
 //#region src/plugin.d.ts
 interface BambooVitePluginOptions {
-  /**
-   * Rewrite statically-resolvable `css()` and pattern calls into literal class
-   * strings, so they cost nothing at runtime.
-   *
-   * On by default, and build-only — it never runs in `vite dev`, where the parse would land
-   * on every hot update and a dev bundle gains nothing from pre-resolved calls.
-   *
-   * What it buys is per-call CPU, not bytes: the runtime still ships, because dropping it
-   * needs *every* call site in the graph to fold. Bundle size moves slightly against you —
-   * measured at -0.8% raw and +1.0% gzipped on `sandbox/runtime-perf`, since distinct class
-   * literals compress worse than the repeated `css({ … })` calls they replace. Set it to
-   * `false` if that trade is the wrong way round for you, or to keep builds faster: folding
-   * re-parses each module with `ts-morph`, roughly 0.3ms for a small component and 3ms for a
-   * 147-line file with 24 call sites.
-   *
-   * @default true
-   */
-  transform?: boolean;
-  /**
-   * Split a call or element that is only partly static, so the resolvable half becomes a
-   * literal and only the rest keeps its runtime call. On by default.
-   *
-   * Without it a single dynamic value declines the whole site.
-   *
-   * @default true
-   */
-  partial?: boolean;
   /** Path to `bamboo.config.ts`. Resolved the same way the CLI resolves it. */
   configPath?: string;
   cwd?: string;
   /**
-   * Report every call site that did *not* fold, and why, per file. Useful when a call
-   * you expected to collapse still shows up in the bundle.
+   * Report every call site the compiler rejected, and why, per file.
    *
    * @default false
    */
   reportSkipped?: boolean;
   /**
-   * Print a coverage summary when the build finishes: how much folded, and what the
-   * remainder was declined for.
+   * Print a coverage summary when the build finishes: how much compiled, and why any
+   * candidates were rejected.
    *
    * On by default. Without it there is no signal that the transform did anything, and
    * no way to tell a project where everything folds from one where nothing does.
@@ -272,38 +35,30 @@ interface BambooVitePluginOptions {
    */
   reportSummary?: boolean;
   /**
-   * Fail the build when a `css()` or pattern call is left for the runtime.
-   *
-   * The fold's value is not the per-call CPU it saves — it is that a bundle where *every*
-   * such call folded no longer imports `styled-system/css` at all, and the engine behind it
-   * drops out. One survivor keeps the whole thing, so a coverage percentage cannot tell you
-   * whether you got the prize. This can.
-   *
-   * Deliberately silent about `cva`/`sva`. A `cva(...)` definition returns a function and can
-   * never collapse to a class string, so failing on it would make this unusable for anyone
-   * writing recipes — and recipes keep their own much smaller runtime by design. What this
-   * guarantees is narrower and checkable: nothing still calls `css()`.
-   *
-   * Named for what it checks. It was `strict`, which meant nothing in common with
-   * `strictTokens` or a pattern's old `strict` — three unrelated options sharing a word, to
-   * the point that comments in this repo used a bare "strict" for all three.
-   *
-   * @default false
+   * Compact atom names. `true`/`stable` is deterministic across
+   * client and SSR builds. `local` uses the shortest names and is safe only when one build
+   * produces both HTML and CSS. @default true
+   */
+  denseClassNames?: DenseClassNameMode;
+  /**
+   * Maximum complete selections compiled for one runtime `cva`/`sva` call. This bounds
+   * build time and memory for the exact compound-variant decision table. @default 65536
    */
-  failOnUnfolded?: boolean;
+  maxRecipeStates?: number;
 }
 /**
  * Vite integration for Bamboo CSS.
  *
  * Two plugins, because they do unrelated jobs on different schedules. The first emits the
  * stylesheet as a virtual module and runs in dev and build alike — that is the integration,
- * and nothing styles without it. The second is the optional build-time fold.
+ * and nothing styles without it. The second compiles every Bamboo source call in both dev
+ * and build; there is no runtime styling fallback.
  *
- * The fold runs with `enforce: 'pre'` so it sees module source as close as possible to what
+ * The compiler runs with `enforce: 'pre'` so it sees module source as close as possible to what
  * the CSS extractor reads off disk. A plugin that rewrites style calls before bamboo
  * sees them would otherwise make the two disagree, and a folded class could end up
  * with no matching rule.
  */
 declare const bamboocss: (options?: BambooVitePluginOptions) => Plugin[];
 //#endregion
-export { type BambooCssPluginOptions, type BambooVitePluginOptions, type FoldOptions, type FoldResult, type FoldedCall, type RuntimeCss, type SkipReason, type SkippedCall, VIRTUAL_CSS_ID, bamboocss, bamboocss as default, bamboocssCss, createRuntimeCss, foldSource };
+export { type BambooVitePluginOptions, VIRTUAL_CSS_ID, bamboocss, bamboocss as default };