@kbach/react-native 1.0.0-beta.7 → 1.0.0-beta.9

package/dist/jsx-runtime.web.mjs

@@ -1,12 +1,10 @@
 import {
+  Fragment,
   jsx,
   jsxs
-} from "./chunk-5WK55Z56.mjs";
-import "./chunk-T3HPTH62.mjs";
-import {
-  Fragment
-} from "./chunk-DLIXI5OW.mjs";
-import "./chunk-AEVOM2NB.mjs";
+} from "./chunk-YOC3SHF5.mjs";
+import "./chunk-H5Z24XX5.mjs";
+import "./chunk-HK6PDJJK.mjs";
 export {
   Fragment,
   jsx,

package/dist/useColors-CeP5_HvM.d.mts

@@ -0,0 +1,230 @@
+import * as react from 'react';
+import { ReactNode } from 'react';
+
+/**
+ * A plain hex value (static — same in both modes), or a `{ light, dark }`
+ * pair a caller sets manually in their own theme. Fully opt-in per color:
+ * nothing here picks a "dark variant" automatically. Only `useColors()`
+ * (a JS-value read, not a `className`) understands this shape — utility
+ * CLASS resolution (`bg-blue-6`) on native/Expo Go stays plain-string-only,
+ * same as it always was (dark mode for a CLASS is the separate `dark:`
+ * modifier, gated live at resolve time — see `resolve_style.rs`); a
+ * mode-aware entry referenced directly by a class name just doesn't
+ * resolve there, mirroring `resolvers/color.rs`'s own `lookup_hex`
+ * (`ColorValue::Plain` only, `ModeAware` -> `None`) exactly, same as it
+ * would on the web engine too.
+ */
+type ColorEntry = string | {
+    light: string;
+    dark: string;
+};
+/**
+ * Real Tailwind's `theme.container` config, mirroring
+ * `packages/core-engine/src/theme.rs`'s `ContainerConfig` exactly. `center`/
+ * `padding` DO reach native now (unlike the max-width breakpoint ladder,
+ * which is a `css.rs`-only concept with nothing to generate on native at
+ * all) — `resolvers::layout::resolve`'s `"container"` arm is shared by both
+ * dispatchers, and `margin`/`padding` are ordinary RN style properties.
+ */
+interface ContainerConfig {
+    center?: boolean;
+    padding?: string;
+}
+interface ThemeConfig {
+    colors: Record<string, ColorEntry>;
+    spacing: Record<string, number>;
+    screens: Record<string, number>;
+    /**
+     * e.g. "sans" -> "Inter, sans-serif". Optional, matching the Rust
+     * engine's own `#[serde(default)]`. Write it as a real web-shaped
+     * fallback stack even on this native-first package — native's own
+     * resolver strips it down to a single bare name at resolve time (RN's
+     * `fontFamily` prop can't take a fallback list — see
+     * `resolvers/mod.rs`'s `first_font_name`), so the SAME config still
+     * works unmodified on Expo Web, which needs the full stack.
+     */
+    fontFamily?: Record<string, string>;
+    darkMode: 'attribute' | 'class' | 'media';
+    /** Optional, matching `ContainerConfig`'s own `#[serde(default)]` on the Rust side. */
+    container?: ContainerConfig;
+}
+declare const defaultTheme: ThemeConfig;
+declare function setTheme(theme: ThemeConfig): void;
+declare function getTheme(): ThemeConfig;
+
+/**
+ * A `kbach.config.js`-style theme customization — same shape as
+ * @kbach/react's `KbachConfig`, minus mode-aware `{ light, dark }` color
+ * entries in `extend.colors` specifically: aliasing/opacity math here only
+ * ever operates on plain hex (`brand: 'blue-6'`, `brandSoft: 'brand/30'`),
+ * matching `jsEngine/resolvers/color.ts`'s `lookupHex`'s own Plain-only
+ * convention — a reference to an EXISTING color that happens to be
+ * mode-aware (`theme.colors` can hold those now, for `useColors()`; see
+ * `theme.ts`'s own `ColorEntry` doc comment) just doesn't resolve as an
+ * alias, falling through to "literal CSS value" the same way an unknown
+ * name would. A config object goes in, a resolved `ThemeConfig` comes out,
+ * via one PURE function (`resolveKbachConfig`) — no plugins, no
+ * live-update store, nothing to keep "in sync."
+ */
+interface KbachConfig {
+    darkMode?: ThemeConfig['darkMode'];
+    /**
+     * REPLACES the named section of `defaultTheme` entirely — use `extend` to
+     * add instead of replace. `container` isn't here (only under `extend`
+     * below) — see @kbach/react's identical `KbachConfig.theme` doc comment
+     * for why.
+     */
+    theme?: Partial<Pick<ThemeConfig, 'colors' | 'spacing' | 'screens' | 'fontFamily'>>;
+    /** Merges INTO `defaultTheme` (or `theme` above, if also supplied) — the common case. */
+    extend?: {
+        /**
+         * A value is either a literal hex color, or a REFERENCE to another
+         * color name, optionally with an opacity suffix. Two things can be
+         * referenced: a BUILT-IN palette color, always available regardless of
+         * ordering (`accent: 'orange-5'`, `accentSoft: 'orange-5/50'`), or a
+         * custom color defined EARLIER in this same object (`{ brand:
+         * '#ff6b35', brandSoft: 'brand/30' }` — `brandSoft` resolves to
+         * `brand`'s own value at 30% opacity). A string that doesn't match any
+         * known color name is treated as a literal CSS value instead.
+         */
+        colors?: Record<string, string>;
+        spacing?: Record<string, number>;
+        screens?: Record<string, number>;
+        /**
+         * Named font stacks, e.g. `{ display: '"Cal Sans", sans-serif' }` —
+         * adds to (or overrides one of) `defaultTheme.fontFamily`'s three
+         * names. Write it as a real web-shaped fallback stack even though this
+         * is the React Native package — native's own resolver strips it down
+         * to a single bare name at resolve time (RN's `fontFamily` prop can't
+         * take a fallback list), so the SAME config still works unmodified on
+         * Expo Web, which needs the full stack.
+         */
+        fontFamily?: Record<string, string>;
+        /** `{ center: true, padding: '2rem' }` — see `ContainerConfig`'s own doc comment. */
+        container?: ContainerConfig;
+    };
+}
+/** Merges a `KbachConfig` into `defaultTheme` — a pure function, no side effects. */
+declare function resolveKbachConfig(config: KbachConfig): ThemeConfig;
+/** `resolveKbachConfig()` + `setTheme()` in one call — the usual entry point from app code. */
+declare function applyKbachConfig(config: KbachConfig): ThemeConfig;
+
+/**
+ * Native port of @kbach/react's darkModeStore.ts — same architecture (a
+ * single module-level store is the real source of truth;
+ * ThemeProvider/useTheme are a thin, OPTIONAL wrapper around it; every
+ * function here works standalone with no provider mounted anywhere), with
+ * two real platform differences from the web version:
+ *
+ * 1. No persistence. There's no React-Native-builtin equivalent of
+ *    localStorage — adding one would mean forcing a real native dependency
+ *    (e.g. @react-native-async-storage/async-storage) on every consumer,
+ *    even ones that don't want it. The mode always starts at 'system' on a
+ *    fresh app launch. If you want persistence, read your own storage at
+ *    startup (before your first render) and call setGlobalThemeMode() with
+ *    the result — same "seed once, no built-in write-back" shape as
+ *    seedDefaultMode() below, just driven by your own storage instead of
+ *    one this package picks for you.
+ * 2. No DOM to "apply" the resolved mode to. On web, applyToDom() flips a
+ *    class/attribute the generated CSS's `dark:` selectors match against.
+ *    On native there's no CSS at all — nativeBridge.ts's resolveStyle()
+ *    reads getGlobalDarkMode() directly on every call instead of querying
+ *    Appearance.getColorScheme() itself, which is what actually makes an
+ *    explicit override affect rendering (previously that function always
+ *    read the raw OS setting, so it had no way to reflect a user choice —
+ *    see nativeBridge.ts's own comment on this for why that's the one
+ *    genuinely fixed bug this change introduces, not just a new feature).
+ */
+type ThemeMode = 'light' | 'dark' | 'system';
+declare function getGlobalDarkMode(): boolean;
+declare function getGlobalThemeMode(): ThemeMode;
+/** Explicit user choice — takes priority over any later `<ThemeProvider defaultMode>` seed (see `seedDefaultMode` below). Not persisted; see this module's own doc comment. */
+declare function setGlobalThemeMode(nextMode: ThemeMode): void;
+declare function toggleGlobalDarkMode(): void;
+declare function subscribeGlobalDarkMode(listener: () => void): () => void;
+
+interface ThemeState {
+    mode: ThemeMode;
+    isDark: boolean;
+    setMode: (mode: ThemeMode) => void;
+    toggle: () => void;
+}
+/**
+ * The one hook for reading and writing Kbach's dark-mode state. Reads
+ * `darkModeStore.ts`'s global store directly via `useSyncExternalStore` —
+ * that module-level store, not React Context, is the actual source of
+ * truth (every provider used to just mirror it into a Context value), so
+ * this works from ANY component, with or without a `<ThemeProvider>`
+ * mounted anywhere in the tree. `<ThemeProvider>` still exists, but purely
+ * as an optional convenience for seeding an app's initial `defaultMode` —
+ * see its own doc comment. No server-snapshot argument (unlike
+ * @kbach/react's web version) — React Native has no SSR concept at all,
+ * so there's no third argument for `useSyncExternalStore` to need.
+ */
+declare function useTheme(): ThemeState;
+
+interface ThemeProviderProps {
+    children: ReactNode;
+    /**
+     * Applied once, on this provider's first mount, but ONLY if nothing has
+     * made an explicit mode choice yet (see
+     * `darkModeStore.ts::seedDefaultMode`) — an explicit prior choice always
+     * wins over a component's own default. Unlike @kbach/react's web
+     * version, there's no persisted value to check here — see
+     * darkModeStore.ts's own doc comment on why this package doesn't persist
+     * the mode across app launches.
+     */
+    defaultMode?: ThemeMode;
+}
+/**
+ * Optional — `useTheme()` reads `darkModeStore.ts`'s global store directly
+ * and works anywhere without this mounted at all. The only thing this
+ * component does is seed that store's initial `defaultMode` once, for apps
+ * that want to declare a startup default in JSX rather than calling
+ * `setGlobalThemeMode()` imperatively before their first render. It
+ * renders `children` as-is — no Context.Provider, since there's no value
+ * left to distribute; `useTheme()` never reads from Context.
+ *
+ * Because the store is global, MULTIPLE mounted providers would each try
+ * to seed the exact same store rather than getting their own scoped
+ * state — mounting more than one is very likely a mistake, so this warns
+ * once in dev.
+ */
+declare function ThemeProvider({ children, defaultMode }: ThemeProviderProps): react.JSX.Element;
+
+interface ColorScale {
+    /** `colors.blue[6]` -> raw value */
+    readonly [shade: number]: string;
+    /** `colors.blue['6/50']` -> shade 6 at 50% opacity */
+    readonly [key: string]: string;
+}
+type ColorsAPI = {
+    /** `colors.white`, `colors.blue` (a shade family), ... */
+    readonly [name: string]: string | ColorScale;
+} & {
+    /** Applies an opacity (0–100) to any color string this hook can return. */
+    readonly alpha: (color: string, opacity?: number) => string;
+};
+/**
+ * Resolved theme colors as real values — for anywhere you need an actual
+ * color (a chart library prop, a raw SVG `fill`), not a `className`. Ported
+ * from old-kbach's `useColors()`, adapted to this engine's flat
+ * `"blue-6"`-keyed palette (`colors.blue[6]` looks up `"blue-6"`).
+ *
+ * Any color — a shade-family entry like `"blue-6"` or a standalone name —
+ * can be defined in the theme as either a plain string (static, same in
+ * both modes) or a `{ light, dark }` pair — fully manual, no automatic
+ * shade-shifting or other assumption about what a "dark variant" should
+ * be; see `resolveEntry`'s own doc comment for how a `{ light, dark }`
+ * entry resolves on this platform specifically.
+ *
+ * ```ts
+ * const colors = useColors();
+ * colors.blue[6];        // "#2563eb" — static, same value in both modes
+ * colors.blue['6/50'];   // same, at 50% opacity
+ * colors.brand;          // resolves per isDark if defined as { light, dark }
+ * ```
+ */
+declare function useColors(): ColorsAPI;
+
+export { type ColorEntry as C, type KbachConfig as K, type ThemeConfig as T, type ColorScale as a, type ColorsAPI as b, type ContainerConfig as c, type ThemeMode as d, ThemeProvider as e, type ThemeProviderProps as f, type ThemeState as g, applyKbachConfig as h, defaultTheme as i, getGlobalDarkMode as j, getGlobalThemeMode as k, getTheme as l, setTheme as m, subscribeGlobalDarkMode as n, useTheme as o, resolveKbachConfig as r, setGlobalThemeMode as s, toggleGlobalDarkMode as t, useColors as u };

package/dist/useColors-CeP5_HvM.d.ts

@@ -0,0 +1,230 @@
+import * as react from 'react';
+import { ReactNode } from 'react';
+
+/**
+ * A plain hex value (static — same in both modes), or a `{ light, dark }`
+ * pair a caller sets manually in their own theme. Fully opt-in per color:
+ * nothing here picks a "dark variant" automatically. Only `useColors()`
+ * (a JS-value read, not a `className`) understands this shape — utility
+ * CLASS resolution (`bg-blue-6`) on native/Expo Go stays plain-string-only,
+ * same as it always was (dark mode for a CLASS is the separate `dark:`
+ * modifier, gated live at resolve time — see `resolve_style.rs`); a
+ * mode-aware entry referenced directly by a class name just doesn't
+ * resolve there, mirroring `resolvers/color.rs`'s own `lookup_hex`
+ * (`ColorValue::Plain` only, `ModeAware` -> `None`) exactly, same as it
+ * would on the web engine too.
+ */
+type ColorEntry = string | {
+    light: string;
+    dark: string;
+};
+/**
+ * Real Tailwind's `theme.container` config, mirroring
+ * `packages/core-engine/src/theme.rs`'s `ContainerConfig` exactly. `center`/
+ * `padding` DO reach native now (unlike the max-width breakpoint ladder,
+ * which is a `css.rs`-only concept with nothing to generate on native at
+ * all) — `resolvers::layout::resolve`'s `"container"` arm is shared by both
+ * dispatchers, and `margin`/`padding` are ordinary RN style properties.
+ */
+interface ContainerConfig {
+    center?: boolean;
+    padding?: string;
+}
+interface ThemeConfig {
+    colors: Record<string, ColorEntry>;
+    spacing: Record<string, number>;
+    screens: Record<string, number>;
+    /**
+     * e.g. "sans" -> "Inter, sans-serif". Optional, matching the Rust
+     * engine's own `#[serde(default)]`. Write it as a real web-shaped
+     * fallback stack even on this native-first package — native's own
+     * resolver strips it down to a single bare name at resolve time (RN's
+     * `fontFamily` prop can't take a fallback list — see
+     * `resolvers/mod.rs`'s `first_font_name`), so the SAME config still
+     * works unmodified on Expo Web, which needs the full stack.
+     */
+    fontFamily?: Record<string, string>;
+    darkMode: 'attribute' | 'class' | 'media';
+    /** Optional, matching `ContainerConfig`'s own `#[serde(default)]` on the Rust side. */
+    container?: ContainerConfig;
+}
+declare const defaultTheme: ThemeConfig;
+declare function setTheme(theme: ThemeConfig): void;
+declare function getTheme(): ThemeConfig;
+
+/**
+ * A `kbach.config.js`-style theme customization — same shape as
+ * @kbach/react's `KbachConfig`, minus mode-aware `{ light, dark }` color
+ * entries in `extend.colors` specifically: aliasing/opacity math here only
+ * ever operates on plain hex (`brand: 'blue-6'`, `brandSoft: 'brand/30'`),
+ * matching `jsEngine/resolvers/color.ts`'s `lookupHex`'s own Plain-only
+ * convention — a reference to an EXISTING color that happens to be
+ * mode-aware (`theme.colors` can hold those now, for `useColors()`; see
+ * `theme.ts`'s own `ColorEntry` doc comment) just doesn't resolve as an
+ * alias, falling through to "literal CSS value" the same way an unknown
+ * name would. A config object goes in, a resolved `ThemeConfig` comes out,
+ * via one PURE function (`resolveKbachConfig`) — no plugins, no
+ * live-update store, nothing to keep "in sync."
+ */
+interface KbachConfig {
+    darkMode?: ThemeConfig['darkMode'];
+    /**
+     * REPLACES the named section of `defaultTheme` entirely — use `extend` to
+     * add instead of replace. `container` isn't here (only under `extend`
+     * below) — see @kbach/react's identical `KbachConfig.theme` doc comment
+     * for why.
+     */
+    theme?: Partial<Pick<ThemeConfig, 'colors' | 'spacing' | 'screens' | 'fontFamily'>>;
+    /** Merges INTO `defaultTheme` (or `theme` above, if also supplied) — the common case. */
+    extend?: {
+        /**
+         * A value is either a literal hex color, or a REFERENCE to another
+         * color name, optionally with an opacity suffix. Two things can be
+         * referenced: a BUILT-IN palette color, always available regardless of
+         * ordering (`accent: 'orange-5'`, `accentSoft: 'orange-5/50'`), or a
+         * custom color defined EARLIER in this same object (`{ brand:
+         * '#ff6b35', brandSoft: 'brand/30' }` — `brandSoft` resolves to
+         * `brand`'s own value at 30% opacity). A string that doesn't match any
+         * known color name is treated as a literal CSS value instead.
+         */
+        colors?: Record<string, string>;
+        spacing?: Record<string, number>;
+        screens?: Record<string, number>;
+        /**
+         * Named font stacks, e.g. `{ display: '"Cal Sans", sans-serif' }` —
+         * adds to (or overrides one of) `defaultTheme.fontFamily`'s three
+         * names. Write it as a real web-shaped fallback stack even though this
+         * is the React Native package — native's own resolver strips it down
+         * to a single bare name at resolve time (RN's `fontFamily` prop can't
+         * take a fallback list), so the SAME config still works unmodified on
+         * Expo Web, which needs the full stack.
+         */
+        fontFamily?: Record<string, string>;
+        /** `{ center: true, padding: '2rem' }` — see `ContainerConfig`'s own doc comment. */
+        container?: ContainerConfig;
+    };
+}
+/** Merges a `KbachConfig` into `defaultTheme` — a pure function, no side effects. */
+declare function resolveKbachConfig(config: KbachConfig): ThemeConfig;
+/** `resolveKbachConfig()` + `setTheme()` in one call — the usual entry point from app code. */
+declare function applyKbachConfig(config: KbachConfig): ThemeConfig;
+
+/**
+ * Native port of @kbach/react's darkModeStore.ts — same architecture (a
+ * single module-level store is the real source of truth;
+ * ThemeProvider/useTheme are a thin, OPTIONAL wrapper around it; every
+ * function here works standalone with no provider mounted anywhere), with
+ * two real platform differences from the web version:
+ *
+ * 1. No persistence. There's no React-Native-builtin equivalent of
+ *    localStorage — adding one would mean forcing a real native dependency
+ *    (e.g. @react-native-async-storage/async-storage) on every consumer,
+ *    even ones that don't want it. The mode always starts at 'system' on a
+ *    fresh app launch. If you want persistence, read your own storage at
+ *    startup (before your first render) and call setGlobalThemeMode() with
+ *    the result — same "seed once, no built-in write-back" shape as
+ *    seedDefaultMode() below, just driven by your own storage instead of
+ *    one this package picks for you.
+ * 2. No DOM to "apply" the resolved mode to. On web, applyToDom() flips a
+ *    class/attribute the generated CSS's `dark:` selectors match against.
+ *    On native there's no CSS at all — nativeBridge.ts's resolveStyle()
+ *    reads getGlobalDarkMode() directly on every call instead of querying
+ *    Appearance.getColorScheme() itself, which is what actually makes an
+ *    explicit override affect rendering (previously that function always
+ *    read the raw OS setting, so it had no way to reflect a user choice —
+ *    see nativeBridge.ts's own comment on this for why that's the one
+ *    genuinely fixed bug this change introduces, not just a new feature).
+ */
+type ThemeMode = 'light' | 'dark' | 'system';
+declare function getGlobalDarkMode(): boolean;
+declare function getGlobalThemeMode(): ThemeMode;
+/** Explicit user choice — takes priority over any later `<ThemeProvider defaultMode>` seed (see `seedDefaultMode` below). Not persisted; see this module's own doc comment. */
+declare function setGlobalThemeMode(nextMode: ThemeMode): void;
+declare function toggleGlobalDarkMode(): void;
+declare function subscribeGlobalDarkMode(listener: () => void): () => void;
+
+interface ThemeState {
+    mode: ThemeMode;
+    isDark: boolean;
+    setMode: (mode: ThemeMode) => void;
+    toggle: () => void;
+}
+/**
+ * The one hook for reading and writing Kbach's dark-mode state. Reads
+ * `darkModeStore.ts`'s global store directly via `useSyncExternalStore` —
+ * that module-level store, not React Context, is the actual source of
+ * truth (every provider used to just mirror it into a Context value), so
+ * this works from ANY component, with or without a `<ThemeProvider>`
+ * mounted anywhere in the tree. `<ThemeProvider>` still exists, but purely
+ * as an optional convenience for seeding an app's initial `defaultMode` —
+ * see its own doc comment. No server-snapshot argument (unlike
+ * @kbach/react's web version) — React Native has no SSR concept at all,
+ * so there's no third argument for `useSyncExternalStore` to need.
+ */
+declare function useTheme(): ThemeState;
+
+interface ThemeProviderProps {
+    children: ReactNode;
+    /**
+     * Applied once, on this provider's first mount, but ONLY if nothing has
+     * made an explicit mode choice yet (see
+     * `darkModeStore.ts::seedDefaultMode`) — an explicit prior choice always
+     * wins over a component's own default. Unlike @kbach/react's web
+     * version, there's no persisted value to check here — see
+     * darkModeStore.ts's own doc comment on why this package doesn't persist
+     * the mode across app launches.
+     */
+    defaultMode?: ThemeMode;
+}
+/**
+ * Optional — `useTheme()` reads `darkModeStore.ts`'s global store directly
+ * and works anywhere without this mounted at all. The only thing this
+ * component does is seed that store's initial `defaultMode` once, for apps
+ * that want to declare a startup default in JSX rather than calling
+ * `setGlobalThemeMode()` imperatively before their first render. It
+ * renders `children` as-is — no Context.Provider, since there's no value
+ * left to distribute; `useTheme()` never reads from Context.
+ *
+ * Because the store is global, MULTIPLE mounted providers would each try
+ * to seed the exact same store rather than getting their own scoped
+ * state — mounting more than one is very likely a mistake, so this warns
+ * once in dev.
+ */
+declare function ThemeProvider({ children, defaultMode }: ThemeProviderProps): react.JSX.Element;
+
+interface ColorScale {
+    /** `colors.blue[6]` -> raw value */
+    readonly [shade: number]: string;
+    /** `colors.blue['6/50']` -> shade 6 at 50% opacity */
+    readonly [key: string]: string;
+}
+type ColorsAPI = {
+    /** `colors.white`, `colors.blue` (a shade family), ... */
+    readonly [name: string]: string | ColorScale;
+} & {
+    /** Applies an opacity (0–100) to any color string this hook can return. */
+    readonly alpha: (color: string, opacity?: number) => string;
+};
+/**
+ * Resolved theme colors as real values — for anywhere you need an actual
+ * color (a chart library prop, a raw SVG `fill`), not a `className`. Ported
+ * from old-kbach's `useColors()`, adapted to this engine's flat
+ * `"blue-6"`-keyed palette (`colors.blue[6]` looks up `"blue-6"`).
+ *
+ * Any color — a shade-family entry like `"blue-6"` or a standalone name —
+ * can be defined in the theme as either a plain string (static, same in
+ * both modes) or a `{ light, dark }` pair — fully manual, no automatic
+ * shade-shifting or other assumption about what a "dark variant" should
+ * be; see `resolveEntry`'s own doc comment for how a `{ light, dark }`
+ * entry resolves on this platform specifically.
+ *
+ * ```ts
+ * const colors = useColors();
+ * colors.blue[6];        // "#2563eb" — static, same value in both modes
+ * colors.blue['6/50'];   // same, at 50% opacity
+ * colors.brand;          // resolves per isDark if defined as { light, dark }
+ * ```
+ */
+declare function useColors(): ColorsAPI;
+
+export { type ColorEntry as C, type KbachConfig as K, type ThemeConfig as T, type ColorScale as a, type ColorsAPI as b, type ContainerConfig as c, type ThemeMode as d, ThemeProvider as e, type ThemeProviderProps as f, type ThemeState as g, applyKbachConfig as h, defaultTheme as i, getGlobalDarkMode as j, getGlobalThemeMode as k, getTheme as l, setTheme as m, subscribeGlobalDarkMode as n, useTheme as o, resolveKbachConfig as r, setGlobalThemeMode as s, toggleGlobalDarkMode as t, useColors as u };

package/package.json

@@ -1,8 +1,18 @@
 {
   "name": "@kbach/react-native",
-  "version": "1.0.0-beta.7",
-  "description": "Kbach's utility-class styling engine for React Native — the same class names as @kbach/react, resolved to a StyleSheet-ready style object via a Kotlin/JNI TurboModule (native) or the same WASM engine @kbach/react uses (Expo Web / react-native-web). Ships its own native Android module — one npm install, no separate native package. Beta. Native is Android-only (no iOS bridge yet); works with the React Native CLI or an Expo dev client (not Expo Go, which cannot load any custom native module).",
-  "keywords": ["css", "react-native", "expo", "tailwind", "utility-first", "styling", "android", "web", "wasm"],
+  "version": "1.0.0-beta.9",
+  "description": "Kbach's utility-class styling engine for React Native — the same class names as @kbach/react, resolved to a StyleSheet-ready style object via a Kotlin/JNI TurboModule (native), the same WASM engine @kbach/react uses (Expo Web / react-native-web), or a pure-JS fallback engine (Expo Go). Ships its own native Android module — one npm install, no separate native package. Beta. Native is Android-only (no iOS bridge yet); works with the React Native CLI, an Expo dev client, AND Expo Go (a reduced-coverage pure-JS fallback, since Expo Go can't load any custom native module).",
+  "keywords": [
+    "css",
+    "react-native",
+    "expo",
+    "tailwind",
+    "utility-first",
+    "styling",
+    "android",
+    "web",
+    "wasm"
+  ],
   "license": "MIT",
   "author": "semsakadanupol",
   "repository": {
@@ -17,7 +27,14 @@
   "publishConfig": {
     "access": "public"
   },
-  "files": ["dist", "src/babel-plugin.js", "android/build.gradle", "android/src", "specs", "react-native.config.js"],
+  "files": [
+    "dist",
+    "src/babel-plugin.js",
+    "android/build.gradle",
+    "android/src",
+    "specs",
+    "react-native.config.js"
+  ],
   "source": "./src/index.ts",
   "main": "./dist/index.js",
   "module": "./dist/index.mjs",
@@ -79,6 +96,7 @@
   "devDependencies": {
     "@types/react": "^19.2.0",
     "@types/react-test-renderer": "^19.1.0",
+    "jsdom": "^30.0.1",
     "react-native": "^0.87.0",
     "react-test-renderer": "^19.2.0",
     "tsup": "^8.0.0",

package/src/babel-plugin.js

@@ -1,5 +1,9 @@
 'use strict';
 
+const path = require('path');
+const fs = require('fs');
+const template = require('@babel/template').default;
+
 /**
  * Injects a per-file `@jsxImportSource @kbach/react-native` pragma comment
  * so Metro's JSX transform routes className resolution through
@@ -19,9 +23,67 @@
  * Deliberately NOT porting old-kbach's build-time class-resolution half
  * (the __kbachStyles fast path) — resolution happens at the (already
  * synchronous) native-bridge call inside the jsx-runtime instead (see
- * nativeBridge.ts), so this plugin's only job is the pragma injection.
+ * nativeBridge.ts), so this plugin's only job is the pragma injection —
+ * PLUS one more, added later: auto-applying `kbach.config.js` if one
+ * exists (see `getConfigStatement`'s own doc comment), so a project never
+ * needs its own explicit `applyKbachConfig(kbachConfig)` call at all. That
+ * addition deliberately still stops short of old-kbach's own version of
+ * this (an mtime-polling live-reload of the config, re-checked on every
+ * file) — a Babel-plugin-level change needs a dev-server restart to take
+ * effect either way, so a one-time check per (root, process) pair is
+ * enough, and much simpler to reason about.
+ */
+
+// Keyed by the root directory checked — undefined = not checked yet for
+// that root, null = checked, no kbach.config.js found there. A Babel/Metro
+// worker process transforms many files over its lifetime — this makes the
+// existsSync + template-build work happen ONCE per root, not on every
+// single file `pre()` runs for.
+const _configStatementCache = new Map();
+
+/**
+ * Builds the (uncompiled) AST statement that applies `kbach.config.js`,
+ * cached per `root` after the first call — `null` if no such file exists
+ * there. `root` defaults to `process.cwd()` (how `metro start`/`expo
+ * start` are conventionally invoked) at the plugin's own call site below;
+ * pass `{ configRoot: '...' }` as this plugin's Babel options if your
+ * `kbach.config.js` lives somewhere else (a monorepo where Metro's actual
+ * working directory isn't the app's own root, for instance).
+ *
+ * The injected statement is a plain `require(...).applyKbachConfig(require(...))`
+ * — no try/catch around it. `kbach.config.js`'s own path is only ever
+ * baked in here after `existsSync` already confirmed it exists, so the
+ * only way this could still throw is a genuine bug in that file (a syntax
+ * error, a bad nested require) — letting that surface as a real, visible
+ * Metro bundling error is far better than silently swallowing it: a
+ * developer's real customization would otherwise go missing with zero
+ * indication why, exactly the kind of headache a good default should avoid.
+ *
+ * `@babel/template` builds this from a plain string with the absolute path
+ * JSON-escaped directly into it (correct on Windows too, backslashes and
+ * all) — simpler than building the equivalent `@babel/types` node graph by
+ * hand for one straightforward statement.
  */
-module.exports = function kbachReactNativeBabelPlugin() {
+function getConfigStatement(root) {
+  if (_configStatementCache.has(root)) return _configStatementCache.get(root);
+
+  const configPath = path.join(root, 'kbach.config.js');
+  if (!fs.existsSync(configPath)) {
+    _configStatementCache.set(root, null);
+    return null;
+  }
+
+  const buildStatement = template(
+    `require('@kbach/react-native').applyKbachConfig(require(${JSON.stringify(configPath)}));`,
+  );
+  const statement = buildStatement();
+  _configStatementCache.set(root, statement);
+  return statement;
+}
+
+module.exports = function kbachReactNativeBabelPlugin(_babel, options) {
+  const configRoot = (options && options.configRoot) || process.cwd();
+
   return {
     name: 'kbach-react-native',
     pre(file) {
@@ -33,7 +95,17 @@ module.exports = function kbachReactNativeBabelPlugin() {
       if (!alreadySet) {
         comments.unshift({ type: 'CommentLine', value: ' @jsxImportSource @kbach/react-native' });
       }
+
+      const configStatement = getConfigStatement(configRoot);
+      if (configStatement) {
+        file.ast.program.body.unshift(configStatement);
+      }
     },
     visitor: {},
   };
 };
+
+/** Exported for tests only — clears the per-root config-file cache between test cases. */
+module.exports._resetForTests = function resetForTests() {
+  _configStatementCache.clear();
+};