@kbach/react-native 1.0.0-beta.14 → 1.0.0-beta.16

package/dist/index.d.mts

@@ -1,83 +0,0 @@
-export { C as ColorEntry, a as ColorScale, b as ColorsAPI, c as ContainerConfig, K as KbachConfig, T as ThemeConfig, d as ThemeMode, e as ThemeProvider, f as ThemeProviderProps, g as ThemeState, h as applyKbachConfig, i as defaultTheme, j as getGlobalDarkMode, k as getGlobalThemeMode, l as getTheme, r as resolveKbachConfig, s as setGlobalThemeMode, m as setTheme, n as subscribeGlobalDarkMode, t as toggleGlobalDarkMode, u as useColors, o as useTheme } from './useColors-C6jyCLuG.mjs';
-import 'react';
-
-type StyleValue = string | number | {
-    width: number;
-    height: number;
-};
-interface StyleObject {
-    [key: string]: StyleValue;
-}
-/**
- * Calls the Rust engine via the KbachModule TurboModule (see
- * apps/native-sandbox/android/.../KbachModule.kt and
- * packages/core-engine/src/resolve_style.rs) and returns a plain style
- * object ready for RN's `style` prop. Synchronous — no async init step,
- * unlike the web/WASM path, since JSI-backed TurboModule methods are
- * available as soon as the module is loaded.
- *
- * Reads `getGlobalDarkMode()` (darkModeStore.ts) fresh on every call (no
- * caching) so `dark:` resolves correctly whenever this runs. That store —
- * not a direct `Appearance.getColorScheme()` read, which this function
- * used prior to `<ThemeProvider>` support — is what makes an explicit
- * `setGlobalThemeMode('dark')`/`toggle()` override actually affect
- * rendering; the store itself falls back to tracking `Appearance` live
- * whenever the mode is `'system'` (its own default), so nothing regresses
- * for apps that never touch the override API at all. This function itself
- * has no subscription of its own, so nothing re-renders just because the
- * store's value changed — call `useTheme()` (its `isDark`) somewhere in
- * the tree for that, NOT React Native's own `useColorScheme()`, which only
- * reflects the raw OS setting and would miss an explicit override entirely.
- *
- * Phase 11 originally shipped with live in-place theme switching unverified
- * (a `uiMode` toggle triggered a re-render but `Appearance.getColorScheme()`
- * kept returning a stale value). Root-caused in Phase 12 while debugging an
- * unrelated `active:` failure: `apps/native-sandbox` has its own separate
- * `node_modules/react-native` (excluded from the npm workspace since Phase
- * 5), while `packages/react-native` resolved `react-native` hierarchically
- * up to a *different* copy at the repo root — two physical module
- * instances, so a `useColorScheme()` subscription and an
- * `Appearance.getColorScheme()` read were silently talking to two separate
- * copies of the Appearance module. Fixed by forcing a single instance via
- * `resolver.resolveRequest` in apps/native-sandbox/metro.config.js; live
- * theme switching (and `active:`, the bug that surfaced this) both verified
- * working after the fix — see Phase 12. Still relevant here: darkModeStore.ts
- * itself calls `Appearance.addChangeListener`, so the same dual-instance
- * failure mode would silently break the 'system' fallback path too if that
- * metro.config.js fix ever regressed.
- *
- * `pressed` gates the `active:` modifier — unlike `colorScheme`, there's no
- * system-level getter for "is this element currently pressed"; only RN's
- * `Pressable` ever knows this, so it's passed in directly by the caller
- * (jsx-runtime, from Pressable's own style-function callback) rather than
- * queried here. Defaults to `false` for every other element type.
- *
- * `width` gates `sm:`/`md:`/`lg:`/`xl:`/`2xl:` against the active theme's
- * `screens` scale (resolve_style.rs's `native_modifier_state`) — read fresh
- * from `Dimensions.get('window').width` on every call, the same "no
- * caching, no store" choice `colorScheme`/`pressed` already make, and for
- * the same reason: unlike dark mode there's no explicit-override concept to
- * preserve here (nobody manually overrides their screen width), so a plain
- * synchronous read is enough — no need for the subscribable store
- * darkModeStore.ts is for. As with `colorScheme`, this function has no
- * subscription of its own, so rotating/resizing the window doesn't
- * re-render anything by itself — call RN's own `useWindowDimensions()`
- * somewhere in the tree for that (same role `useColorScheme()` plays for
- * `dark:` in apps/native-sandbox/App.tsx).
- *
- * Falls back to `./jsEngine` (a pure-JS, no-WASM/no-native reimplementation
- * of this same resolution logic — see that directory's own doc comments)
- * when `KbachModule` isn't registered at all — Expo Go, which can never
- * load ANY custom native module (not even Expo's own Modules API), so the
- * TurboModule this file otherwise depends on simply doesn't exist there.
- * `TurboModuleRegistry.get` (not `.getEnforcing`, which throws) is what
- * makes this detectable at all — `get` returns `null`/`undefined` instead.
- * A real dev-client/CLI build always has the module registered, so this
- * fallback only ever activates in Expo Go itself; everywhere else behaves
- * exactly as before. The JS engine covers a strict subset of what the
- * native/WASM engines resolve (see jsEngine/resolveUtilityNative.ts) — an
- * intentional, documented parity gap, not a bug.
- */
-declare function resolveStyle(classString: string, pressed?: boolean): StyleObject;
-
-export { type StyleObject, resolveStyle };

package/dist/index.mjs

@@ -1,38 +0,0 @@
-import {
-  ThemeProvider,
-  applyKbachConfig,
-  resolveKbachConfig,
-  useColors,
-  useTheme
-} from "./chunk-TDWBXJH5.mjs";
-import {
-  resolveStyle
-} from "./chunk-JMNJCPGK.mjs";
-import {
-  getGlobalDarkMode,
-  getGlobalThemeMode,
-  setGlobalThemeMode,
-  subscribeGlobalDarkMode,
-  toggleGlobalDarkMode
-} from "./chunk-RBJXE32L.mjs";
-import {
-  defaultTheme,
-  getTheme,
-  setTheme
-} from "./chunk-HK6PDJJK.mjs";
-export {
-  ThemeProvider,
-  applyKbachConfig,
-  defaultTheme,
-  getGlobalDarkMode,
-  getGlobalThemeMode,
-  getTheme,
-  resolveKbachConfig,
-  resolveStyle,
-  setGlobalThemeMode,
-  setTheme,
-  subscribeGlobalDarkMode,
-  toggleGlobalDarkMode,
-  useColors,
-  useTheme
-};

package/dist/index.web.d.mts

@@ -1,15 +0,0 @@
-export { C as ColorEntry, a as ColorScale, b as ColorsAPI, c as ContainerConfig, K as KbachConfig, T as ThemeConfig, d as ThemeMode, e as ThemeProvider, f as ThemeProviderProps, g as ThemeState, h as applyKbachConfig, i as defaultTheme, j as getGlobalDarkMode, k as getGlobalThemeMode, l as getTheme, r as resolveKbachConfig, s as setGlobalThemeMode, m as setTheme, n as subscribeGlobalDarkMode, t as toggleGlobalDarkMode, u as useColors, o as useTheme } from './useColors-C6jyCLuG.mjs';
-import 'react';
-
-/**
- * Resolves `classString` to CSS via the WASM engine, injects every returned
- * rule into a shared `<style data-kbach-rn>` tag (cascade-order-safe — see
- * cssInjector.web.ts), and returns the class string to use as
- * `dataSet={{ kb: <returned value> }}`. MUST use the returned value, not the
- * original input — mode-aware color names (e.g. `bg-surface`) expand into a
- * literal light/dark pair, and the generated rules target that expanded
- * text, not the original.
- */
-declare function resolveClassName(classString: string): string;
-
-export { resolveClassName };

package/dist/jsx-dev-runtime.d.mts

@@ -1,10 +0,0 @@
-import * as react from 'react';
-export { Fragment } from 'react';
-
-declare const jsxDEV: (type: unknown, props: Record<string, unknown> | null, key?: string, isStaticChildren?: boolean, source?: {
-    fileName: string;
-    lineNumber: number;
-    columnNumber: number;
-}, self?: unknown) => react.ReactElement;
-
-export { jsxDEV };

package/dist/jsx-dev-runtime.mjs

@@ -1,18 +0,0 @@
-import {
-  jsx,
-  jsxs
-} from "./chunk-WT6WH54F.mjs";
-import "./chunk-JMNJCPGK.mjs";
-import {
-  Fragment,
-  createJsxDEV
-} from "./chunk-H57O3BJO.mjs";
-import "./chunk-RBJXE32L.mjs";
-import "./chunk-HK6PDJJK.mjs";
-
-// src/jsx-dev-runtime.tsx
-var jsxDEV = createJsxDEV(jsx, jsxs);
-export {
-  Fragment,
-  jsxDEV
-};

package/dist/jsx-dev-runtime.web.d.mts

@@ -1,10 +0,0 @@
-import * as react from 'react';
-export { Fragment } from 'react';
-
-declare const jsxDEV: (type: unknown, props: Record<string, unknown> | null, key?: string, isStaticChildren?: boolean, source?: {
-    fileName: string;
-    lineNumber: number;
-    columnNumber: number;
-}, self?: unknown) => react.ReactElement;
-
-export { jsxDEV };

package/dist/jsx-runtime.d.mts

@@ -1,7 +0,0 @@
-import * as react from 'react';
-export { Fragment, JSX } from 'react';
-
-declare const jsx: (type: unknown, props: Record<string, unknown> | null, key?: string) => react.ReactElement;
-declare const jsxs: (type: unknown, props: Record<string, unknown> | null, key?: string) => react.ReactElement;
-
-export { jsx, jsxs };

package/dist/jsx-runtime.mjs

@@ -1,15 +0,0 @@
-import {
-  jsx,
-  jsxs
-} from "./chunk-WT6WH54F.mjs";
-import "./chunk-JMNJCPGK.mjs";
-import {
-  Fragment
-} from "./chunk-H57O3BJO.mjs";
-import "./chunk-RBJXE32L.mjs";
-import "./chunk-HK6PDJJK.mjs";
-export {
-  Fragment,
-  jsx,
-  jsxs
-};

package/dist/jsx-runtime.web.d.mts

@@ -1,7 +0,0 @@
-import * as react from 'react';
-export { Fragment, JSX } from 'react';
-
-declare const jsx: (type: unknown, props: Record<string, unknown> | null, key?: string) => react.ReactElement;
-declare const jsxs: (type: unknown, props: Record<string, unknown> | null, key?: string) => react.ReactElement;
-
-export { jsx, jsxs };

package/dist/useColors-C6jyCLuG.d.mts

@@ -1,239 +0,0 @@
-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 };