@kbach/react-native 1.0.0-beta.1 → 1.0.0-beta.10

package/dist/jsx-runtime.web.mjs

@@ -0,0 +1,12 @@
+import {
+  Fragment,
+  jsx,
+  jsxs
+} from "./chunk-YOC3SHF5.mjs";
+import "./chunk-H5Z24XX5.mjs";
+import "./chunk-HK6PDJJK.mjs";
+export {
+  Fragment,
+  jsx,
+  jsxs
+};

package/dist/useColors-C6jyCLuG.d.mts

@@ -0,0 +1,239 @@
+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. `applyToDom` below IS needed here, unlike what an earlier version of
+ *    this file's own comment claimed ("no DOM to apply the resolved mode
+ *    to") — that reasoning only holds for real native (Android/iOS), where
+ *    nativeBridge.ts's resolveStyle() reads getGlobalDarkMode() directly on
+ *    every call, no DOM involved at all. This file is ALSO used by Expo
+ *    Web, though (no `.web.ts` sibling — Metro has nothing to swap in), and
+ *    Expo Web resolves `dark:` classes to REAL CSS with `[data-theme=
+ *    "dark"]`-style selectors (see nativeBridge.web.ts) that only ever
+ *    match if something writes that attribute to the DOM — nothing did,
+ *    which is exactly why toggling the mode changed `useTheme()`'s own
+ *    state (a consumer reading `mode`/`isDark` directly, e.g. for a label,
+ *    updated correctly) while every `dark:`-prefixed style silently never
+ *    applied. `typeof document === 'undefined'` is what makes one function
+ *    safe on both platforms: real native's Hermes has no `document` global
+ *    at all (not even `undefined` as a defined-but-empty value — genuinely
+ *    unset, which `typeof` can check without throwing), so this always
+ *    no-ops there, while Expo Web's react-native-web renders into a real
+ *    browser DOM where it's needed.
+ */
+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-C6jyCLuG.d.ts

@@ -0,0 +1,239 @@
+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. `applyToDom` below IS needed here, unlike what an earlier version of
+ *    this file's own comment claimed ("no DOM to apply the resolved mode
+ *    to") — that reasoning only holds for real native (Android/iOS), where
+ *    nativeBridge.ts's resolveStyle() reads getGlobalDarkMode() directly on
+ *    every call, no DOM involved at all. This file is ALSO used by Expo
+ *    Web, though (no `.web.ts` sibling — Metro has nothing to swap in), and
+ *    Expo Web resolves `dark:` classes to REAL CSS with `[data-theme=
+ *    "dark"]`-style selectors (see nativeBridge.web.ts) that only ever
+ *    match if something writes that attribute to the DOM — nothing did,
+ *    which is exactly why toggling the mode changed `useTheme()`'s own
+ *    state (a consumer reading `mode`/`isDark` directly, e.g. for a label,
+ *    updated correctly) while every `dark:`-prefixed style silently never
+ *    applied. `typeof document === 'undefined'` is what makes one function
+ *    safe on both platforms: real native's Hermes has no `document` global
+ *    at all (not even `undefined` as a defined-but-empty value — genuinely
+ *    unset, which `typeof` can check without throwing), so this always
+ *    no-ops there, while Expo Web's react-native-web renders into a real
+ *    browser DOM where it's needed.
+ */
+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.1",
-  "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. Beta, Android-only.",
-  "keywords": ["css", "react-native", "tailwind", "utility-first", "styling", "android"],
+  "version": "1.0.0-beta.10",
+  "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"],
+  "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",
@@ -26,18 +43,42 @@
     ".": {
       "types": "./dist/index.d.ts",
       "source": "./src/index.ts",
+      "browser": {
+        "import": "./dist/index.web.mjs",
+        "require": "./dist/index.web.js"
+      },
+      "node": {
+        "import": "./dist/index.web.mjs",
+        "require": "./dist/index.web.js"
+      },
       "import": "./dist/index.mjs",
       "require": "./dist/index.js"
     },
     "./jsx-runtime": {
       "types": "./dist/jsx-runtime.d.ts",
       "source": "./src/jsx-runtime.tsx",
+      "browser": {
+        "import": "./dist/jsx-runtime.web.mjs",
+        "require": "./dist/jsx-runtime.web.js"
+      },
+      "node": {
+        "import": "./dist/jsx-runtime.web.mjs",
+        "require": "./dist/jsx-runtime.web.js"
+      },
       "import": "./dist/jsx-runtime.mjs",
       "require": "./dist/jsx-runtime.js"
     },
     "./jsx-dev-runtime": {
       "types": "./dist/jsx-dev-runtime.d.ts",
       "source": "./src/jsx-dev-runtime.tsx",
+      "browser": {
+        "import": "./dist/jsx-dev-runtime.web.mjs",
+        "require": "./dist/jsx-dev-runtime.web.js"
+      },
+      "node": {
+        "import": "./dist/jsx-dev-runtime.web.mjs",
+        "require": "./dist/jsx-dev-runtime.web.js"
+      },
       "import": "./dist/jsx-dev-runtime.mjs",
       "require": "./dist/jsx-dev-runtime.js"
     },
@@ -48,14 +89,14 @@
     "dev": "tsup --watch",
     "test": "vitest run --passWithNoTests",
     "lint": "tsc --noEmit",
-    "generate:colors": "node ../core-engine/scripts/generate-palette.mjs src/generatedPalette.ts"
-  },
-  "dependencies": {
-    "@kbach/android": "1.0.0-beta.0"
+    "generate:colors": "node ../core-engine/scripts/generate-palette.mjs src/generatedPalette.ts",
+    "generate:wasm-base64": "node ../core-engine/scripts/generate-wasm-base64.mjs src/wasmBinary.generated.ts",
+    "generate:web-glue": "node ../core-engine/scripts/generate-web-glue.mjs src/wasmGlue.generated.ts"
   },
   "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",
@@ -65,5 +106,13 @@
   "peerDependencies": {
     "react": ">=18.0.0",
     "react-native": ">=0.70.0"
+  },
+  "codegenConfig": {
+    "name": "KbachSpec",
+    "type": "modules",
+    "jsSrcsDir": "specs",
+    "android": {
+      "javaPackageName": "com.kbachnative"
+    }
   }
 }

package/react-native.config.js

@@ -0,0 +1,29 @@
+/**
+ * Explicit override for React Native autolinking's Android package
+ * detection, which otherwise guesses `<packageName>.<PackageClassName>`
+ * from either AndroidManifest.xml's `package` attribute or (when absent,
+ * our case) build.gradle's `namespace` — see cli-config-android's
+ * getPackageName. That guess is wrong here on purpose: KbachModule.kt/
+ * KbachPackage.kt declare `package com.kbachnative` (chosen to match the
+ * JNI extern symbol names in packages/core-engine/src/jni_bridge.rs), but
+ * this module's Gradle `namespace` has to be a DIFFERENT value
+ * (com.kbachnative.nativemodule, see android/build.gradle's own comment)
+ * since AGP requires unique namespaces per module and the consuming app
+ * itself already claims "com.kbachnative" as its own. Without this
+ * override, the generated PackageList.java imports the non-existent
+ * `com.kbachnative.nativemodule.KbachPackage` and the app fails to
+ * compile. (A `package="com.kbachnative"` attribute in AndroidManifest.xml
+ * was tried first instead — simpler on paper — but AGP 9+ hard-errors on a
+ * manifest package that doesn't match the namespace, so this explicit
+ * config override is the only working fix.)
+ */
+module.exports = {
+  dependency: {
+    platforms: {
+      android: {
+        packageImportPath: 'import com.kbachnative.KbachPackage;',
+        packageInstance: 'new KbachPackage()',
+      },
+    },
+  },
+};

package/specs/NativeKbachModule.ts

@@ -0,0 +1,31 @@
+/**
+ * TurboModule spec for KbachModule — RN's Codegen convention requires this
+ * exact `Native<Name>.ts` filename and a default-exported
+ * `TurboModuleRegistry.getEnforcing<Spec>(...)`. Read by Codegen (see this
+ * package's own `codegenConfig` in package.json) to generate the native
+ * glue that ../android/src/main/java/com/kbachnative/KbachModule.kt
+ * implements. Lives in this same package (not the consuming app) alongside
+ * the native Android code it describes — Android autolinking only
+ * discovers native modules from npm dependencies with their own `android/`
+ * folder, not from native code declared directly inside an app, which is
+ * why `@kbach/react-native` ships its own `android/` + `specs/` at all
+ * (see Phase 13) rather than relying on the consuming app to provide one.
+ *
+ * Method names have no `Sync` suffix (unlike the pre-Phase-13 bridge's
+ * `generateCssSync`/`resolveStyleSync`) — every TurboModule call is
+ * synchronous by nature via JSI, so the suffix's whole point (flagging
+ * "this one blocks, unlike normal bridge methods") no longer applies.
+ */
+import type { TurboModule } from 'react-native';
+import { TurboModuleRegistry } from 'react-native';
+
+export interface Spec extends TurboModule {
+  generateCss(classString: string, themeJson: string): string;
+  // `width`: a plain `number` (not the `Int32`/`Float` CodegenTypes
+  // aliases) is Codegen's own default float-numeric mapping — it already
+  // compiles to Kotlin's `Double` on the native side, matching
+  // KbachModule.kt's `width: Double` parameter with no extra type alias.
+  resolveStyle(classString: string, themeJson: string, colorScheme: string, pressed: boolean, width: number): string;
+}
+
+export default TurboModuleRegistry.getEnforcing<Spec>('KbachModule');