@bamboocss/vite 1.21.0 → 1.23.0

package/dist/index.d.cts

@@ -1,8 +1,36 @@
+import { Plugin } from "vite";
 import { Context } from "@bamboocss/core";
 import { Dict, ParserResultInterface } from "@bamboocss/types";
 import MagicString from "magic-string";
-import { Plugin } from "vite";
 
+//#region src/css.d.ts
+/**
+ * What a project imports to get the stylesheet.
+ *
+ * Spelled with a `.css` extension because that is how vite decides what a module is: the
+ * id is all it has for a module with no file behind it, so `virtual:bamboo` would be
+ * 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/runtime-css.d.ts
 /**
  * The generated runtime's `css`, rebuilt in-process from a resolved context.
@@ -33,7 +61,7 @@ declare const createRuntimeCss: (ctx: Context) => RuntimeCss;
  * 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' | 'unsupported-kind' | 'not-imported' | 'no-call-expression' | 'overlapping' | 'empty' | 'unresolved-token';
+type SkipReason = 'dynamic' | 'raw-call' | 'not-foldable' | 'recipe-call' | 'unsupported-kind' | 'not-imported' | 'no-call-expression' | 'overlapping' | 'empty' | 'unresolved-token';
 interface FoldedCall {
   name: string;
   /**
@@ -144,18 +172,35 @@ interface BambooVitePluginOptions {
    * @default true
    */
   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()`.
+   *
+   * @default false
+   */
+  strict?: boolean;
 }
 /**
  * Vite integration for Bamboo CSS.
  *
- * This plugin does not emit CSS — keep your existing PostCSS setup for that. Its only
- * job is the optional build-time fold.
+ * 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.
  *
- * It runs with `enforce: 'pre'` so it sees module source as close as possible to what
+ * The fold 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;
+declare const bamboocss: (options?: BambooVitePluginOptions) => Plugin[];
 //#endregion
-export { type BambooVitePluginOptions, type FoldOptions, type FoldResult, type FoldedCall, type RuntimeCss, type SkipReason, type SkippedCall, bamboocss, bamboocss as default, createRuntimeCss, foldSource };
+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 };

package/dist/index.d.mts

@@ -1,8 +1,36 @@
 import MagicString from "magic-string";
 import { Context } from "@bamboocss/core";
-import { Dict, ParserResultInterface } from "@bamboocss/types";
 import { Plugin } from "vite";
+import { Dict, ParserResultInterface } from "@bamboocss/types";
 
+//#region src/css.d.ts
+/**
+ * What a project imports to get the stylesheet.
+ *
+ * Spelled with a `.css` extension because that is how vite decides what a module is: the
+ * id is all it has for a module with no file behind it, so `virtual:bamboo` would be
+ * 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/runtime-css.d.ts
 /**
  * The generated runtime's `css`, rebuilt in-process from a resolved context.
@@ -33,7 +61,7 @@ declare const createRuntimeCss: (ctx: Context) => RuntimeCss;
  * 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' | 'unsupported-kind' | 'not-imported' | 'no-call-expression' | 'overlapping' | 'empty' | 'unresolved-token';
+type SkipReason = 'dynamic' | 'raw-call' | 'not-foldable' | 'recipe-call' | 'unsupported-kind' | 'not-imported' | 'no-call-expression' | 'overlapping' | 'empty' | 'unresolved-token';
 interface FoldedCall {
   name: string;
   /**
@@ -144,18 +172,35 @@ interface BambooVitePluginOptions {
    * @default true
    */
   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()`.
+   *
+   * @default false
+   */
+  strict?: boolean;
 }
 /**
  * Vite integration for Bamboo CSS.
  *
- * This plugin does not emit CSS — keep your existing PostCSS setup for that. Its only
- * job is the optional build-time fold.
+ * 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.
  *
- * It runs with `enforce: 'pre'` so it sees module source as close as possible to what
+ * The fold 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;
+declare const bamboocss: (options?: BambooVitePluginOptions) => Plugin[];
 //#endregion
-export { type BambooVitePluginOptions, type FoldOptions, type FoldResult, type FoldedCall, type RuntimeCss, type SkipReason, type SkippedCall, bamboocss, bamboocss as default, createRuntimeCss, foldSource };
+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 };