@kbach/react-native 1.0.0-beta.6 → 1.0.0-beta.8

package/README.md

@@ -5,9 +5,12 @@ names as [`@kbach/react`](https://www.npmjs.com/package/@kbach/react),
 resolved to a real `StyleSheet`-ready style object instead of injected CSS.
 
 > **Beta.** Native (Android-only, no iOS bridge yet) resolves through a
-> Kotlin/JNI TurboModule; Expo Web / react-native-web resolves through the
-> same Rust engine compiled to WASM instead — both call the identical
-> resolution logic, so class semantics stay identical everywhere. The
+> Kotlin/JNI TurboModule to an inline style object; Expo Web /
+> react-native-web resolves through the same Rust engine compiled to WASM,
+> but to real generated CSS instead (full modifier support, including
+> `hover:`/`focus:`/etc. — see "Expo Web" below); Expo Go — which can load
+> neither a TurboModule nor WASM — resolves through a third, pure-JS
+> fallback engine with reduced utility coverage (see "Expo Go" below). The
 > native module ships prebuilt (see Setup below) — no Rust toolchain or
 > manual native wiring required on any platform.
 
@@ -22,8 +25,8 @@ prebuilt native `.so` ship inside this same package's own `android/`
 folder. Android's autolinking discovers it automatically the moment it's
 in `node_modules`; no manual `MainApplication.kt` edit needed. Works the
 same way whether your app was created with the React Native CLI or with
-Expo — **except Expo Go**, which can never load this (or any) custom
-native module; see below.
+Expo, **including Expo Go** — see its own section below for the scope
+tradeoff that involves.
 
 ### React Native CLI
 
@@ -47,18 +50,53 @@ one needs (a plain single-app install doesn't need any of that — it's
 only relevant if you're linking packages locally instead of installing
 from npm).
 
-### Expo (native — Android)
-
-**Expo Go can never work with this package, and that isn't specific to
-Kbach.** Expo Go is a single fixed binary Expo pre-builds and ships
-through the app stores, containing only the native code Expo bundled into
-it at their own build time — there is no mechanism for *any* third-party
-package to add native code to it at runtime, whether that's a raw
-TurboModule (what this package uses) or even Expo's own Modules API. This
-is exactly why the **dev client** concept exists: a custom build of your
-app — built once via `expo prebuild`/`expo run:android`, functionally the
-same "real native project" as the CLI path above — that *does* include
-this module:
+### Expo Go
+
+**Works — no prebuild, no dev client, no extra setup.** Expo Go is a
+single fixed binary Expo pre-builds and ships through the app stores,
+containing only the native code Expo bundled into it at their own build
+time — there is no mechanism for *any* third-party package to add native
+code to it at runtime, whether that's a raw TurboModule (what this
+package's Android/Expo-dev-client path uses) or even Expo's own Modules
+API. So instead of trying to load one, this package detects that the
+TurboModule isn't registered (`TurboModuleRegistry.get('KbachModule')`
+returns `null` rather than throwing) and transparently falls back to a
+**third resolution engine**: a pure-JavaScript reimplementation of the
+same class-resolution logic, ported by hand from
+[`resolve_style.rs`](https://github.com/semsakadanupol/kbach/blob/main/packages/core-engine/src/resolve_style.rs)
+and its resolvers (see
+[`src/jsEngine`](https://github.com/semsakadanupol/kbach/blob/main/packages/react-native/src/jsEngine)
+in the repo) — no WASM (Hermes has no `WebAssembly` API at all) and no
+native code, so it can run anywhere plain JS runs, Expo Go included. A
+real dev-client or CLI build always has the TurboModule registered, so
+this fallback activates ONLY inside Expo Go itself; every other
+environment is completely unaffected.
+
+The tradeoff: the JS engine covers layout, spacing, border/radius,
+plain-hex colors (`bg-*`/`text-*`, no opacity composition), font-weight,
+text-transform (`uppercase`/`lowercase`/`capitalize`), text-decoration-line
+(`underline`/`line-through`/`no-underline`), `italic`/`not-italic`, numeric
+line-height and arbitrary letter-spacing, and `shadow-*` — the same
+native-representable subset
+`resolve_utility_native` (the Rust engine's own native dispatcher) covers,
+minus a WASM/JNI dependency. It does **not** cover anything that subset
+already excludes on native (grid, transforms, filters, gradients, DOM-only
+typography like `truncate`/`decoration-*`/`indent-*`, interactivity/scroll
+utilities) — those were never available outside a dev client/CLI build,
+Expo Go doesn't change that. `dark:`/`active:`/`sm:`-`2xl:` modifiers work
+identically to the native/WASM engines (same gating logic, just inlined
+rather than routed through a shared registry). If you hit a class that
+silently doesn't apply only in Expo Go, check whether it resolves under a
+dev client first — if it does, it's outside this fallback's ported scope,
+not a bug in the class itself.
+
+### Expo (dev client / prebuild — Android)
+
+A dev client gets you the *full* native engine (the same one the CLI path
+above uses) instead of the JS fallback above — worth it once you need
+something outside that fallback's scope. Built once via `expo prebuild`/
+`expo run:android`, functionally the same "real native project" as the CLI
+path above:
 
 ```js
 // babel.config.js
@@ -92,26 +130,100 @@ needs (a plain single-app install doesn't need it).
 **Works — no extra setup, no separate package, no init call.** `expo start
 --web` (and EAS's web builds) render through `react-native-web` —
 `View`/`Text`/etc. become real DOM elements with real CSS, not a
-Kotlin/JNI bridge, so on web this package resolves classes through the
-same Rust engine [`@kbach/react`](https://www.npmjs.com/package/@kbach/react)
-uses — WASM instead of JNI — automatically. Metro picks the right
-implementation per platform on its own via this package's `"browser"`
-export condition; your app code and JSX never change. The WASM module
-initializes itself eagerly (synchronously, at import time — no `await`
-needed before your first render, unlike a from-scratch WASM setup).
-
-The only thing this doesn't cover on web is an iOS-parity feature gap —
-everything web-side resolves through the exact same
-[`resolve_style.rs`](https://github.com/semsakadanupol/kbach/blob/main/packages/core-engine/src/resolve_style.rs)
-logic real native uses, so see this README's "What this is" section above
-for what's covered.
+Kotlin/JNI bridge — so on web this package resolves classes through the
+same real-CSS engine
+[`@kbach/react`](https://www.npmjs.com/package/@kbach/react) uses on the
+DOM, not the inline-style-object engine native/Expo Go use. Metro picks
+the right implementation per platform on its own via this package's
+`"browser"` (client bundles) and `"node"` (Expo Router's static-rendering/
+SSR bundles — a genuinely separate resolution axis from `platform: 'web'`,
+see `nativeBridge.web.ts`'s own doc comment) export conditions; your app
+code and JSX never change. The WASM module initializes itself eagerly
+(synchronously, at import time — no `await` needed before your first
+render, unlike a from-scratch WASM setup).
+
+**Full modifier support, including `hover:`/`focus:`/`group-hover:`/
+`has-[...]`/container queries/etc.** — every modifier
+[`registry.rs`](https://github.com/semsakadanupol/kbach/blob/main/packages/core-engine/src/registry.rs)
+knows, not just the `dark:`/`active:`/responsive subset native/Expo Go
+gate via a live JS parameter. This is possible specifically *because* Expo
+Web is real DOM: real CSS selectors (`:hover`, `:focus`, `@media`,
+`@container`, ...) work exactly the way they do for `@kbach/react`, no
+polyfilling needed. The one wrinkle: `react-native-web`'s `View`/`Text`/
+`Pressable` don't forward a `className` prop to the DOM at all (checked
+against its own `forwardedProps` whitelist), so this can't render a
+literal `className` the way `@kbach/react` does on plain DOM. What it uses
+instead: RN's `dataSet` prop (which RNW DOES forward, as real `data-*`
+attributes) carries the resolved class text into a `data-kb="..."`
+attribute, and the generated CSS targets it with `[data-kb~="..."]`
+attribute selectors instead of `.class` selectors — functionally
+identical to a real `className`, just reached through RN's own prop
+system instead. This also means `active:` is now REAL CSS `:active` (the
+browser's own press-state detection), not a `Pressable`-specific style-
+function simulation the way native's `active:` still is — one fewer
+special case, and closer to actual Tailwind's own semantics.
+
+Everything else about this matches `@kbach/react`'s own web engine
+exactly — same
+[`resolve_utility`](https://github.com/semsakadanupol/kbach/blob/main/packages/core-engine/src/resolvers/mod.rs)
+dispatch (not the reduced `resolve_utility_native` subset), so grid,
+transforms, filters, gradients, and DOM-only typography (`truncate`,
+`decoration-*`, etc.) all resolve on Expo Web even though they don't on
+native or Expo Go — see this README's "What this is" section for what's
+covered elsewhere.
+
+#### Expo Router static rendering: `dark:`/responsive on the FIRST paint
+
+If you use [static rendering](https://docs.expo.dev/router/reference/static-rendering/)
+(`web.output: "static"` — Expo Router's SSR/pre-render feature), any
+`dark:`/`sm:`/etc. class on content that's part of the **initial,
+pre-rendered HTML** resolves against whatever the **server** (Node.js, no
+real display/viewport) reports — not the visiting browser's actual OS
+preference or window size. React's hydration then adopts that
+server-rendered markup as-is rather than silently overwriting it with the
+client's own (correct) values, because a `style`-attribute-only difference
+doesn't fail hydration the way a text-content mismatch does. Concretely: a
+user with their OS in dark mode can see a `dark:` class resolve to its
+*light* value on first paint, with no error or warning anywhere.
+
+**This isn't a Kbach bug** — it's the same fundamental constraint every
+OS-preference-based styling system has under SSR (Next.js's own dark-mode
+docs describe the identical problem and fix). The standard fix applies
+here unchanged: don't resolve preference-dependent classes on
+initially-server-rendered content at all; defer them to after your app has
+mounted client-side, e.g.:
+
+```tsx
+import { useEffect, useState } from 'react';
+import { Text, View } from 'react-native';
+
+function ThemedScreen() {
+  const [mounted, setMounted] = useState(false);
+  useEffect(() => setMounted(true), []);
+
+  // Neutral on the server AND on the client's first paint (matches exactly,
+  // no hydration mismatch) — only becomes preference-aware once mounted.
+  return (
+    <View className={mounted ? 'bg-gray-1 dark:bg-gray-12' : 'bg-gray-1'}>
+      <Text>Hello</Text>
+    </View>
+  );
+}
+```
+
+Content that only ever renders client-side (not part of the statically
+pre-rendered route) is unaffected — this only matters for what's visible
+before your first `useEffect` runs.
 
 ## What this is
 
 - A JSX runtime (`@kbach/react-native/jsx-runtime`) that intercepts
-  `className`/`kb` props on every element and calls into the native/WASM
-  bridge (whichever platform you're on) to resolve them to a style object,
-  synchronously, on every render.
+  `className`/`kb` props on every element and calls into the native, WASM,
+  or pure-JS bridge (whichever platform you're on — see the Setup section
+  above), synchronously, on every render. On native and Expo Go this
+  resolves to an inline `style` object; on Expo Web it resolves to real
+  injected CSS plus a `dataSet={{ kb: '...' }}` prop instead — see "Expo
+  Web" below for why the two differ.
 - A Babel plugin (`@kbach/react-native/babel-plugin`) that routes your
   app's own files (never `node_modules`) through that JSX runtime via a
   per-file `@jsxImportSource` pragma.
@@ -129,12 +241,15 @@ for what's covered.
   arbitrary `shadow-[...]` values aren't supported — RN's native shadow
   props can't express an inset shadow, and an arbitrary value is a raw CSS
   string with no mechanical translation into discrete native props.
-- Responsive breakpoints (`sm:`/`md:`/`lg:`/`xl:`/`2xl:`) — gated live
-  against the current window width (`Dimensions.get('window').width`),
-  same mobile-first "min-width and up" semantics as web, and freely
-  combinable with `dark:`/`active:` (e.g. `dark:md:bg-blue-8`). Call RN's
-  own `useWindowDimensions()` somewhere in your tree to re-render on
-  rotation/resize — same role `useColorScheme()` plays for `dark:` below.
+- Responsive breakpoints (`sm:`/`md:`/`lg:`/`xl:`/`2xl:`) — same
+  mobile-first "min-width and up" semantics as web, freely combinable with
+  `dark:`/`active:` (e.g. `dark:md:bg-blue-8`). On native/Expo Go, gated
+  live against the current window width (`Dimensions.get('window').width`)
+  — call RN's own `useWindowDimensions()` somewhere in your tree to
+  re-render on rotation/resize, same role `useColorScheme()` plays for
+  `dark:` below. On Expo Web this is real `@media (min-width: ...)` CSS
+  instead (see "Expo Web" above) — the browser evaluates it continuously
+  on its own, so no `useWindowDimensions()` call is needed there at all.
 
 ## Dark mode
 

package/dist/ThemeContext-Dc5AC-m0.d.mts

@@ -0,0 +1,98 @@
+import * as react from 'react';
+import { ReactNode } from 'react';
+
+interface ThemeConfig {
+    /** Plain hex only, this pass — e.g. "blue-6" -> "#2563eb" */
+    colors: Record<string, string>;
+    spacing: Record<string, number>;
+    screens: Record<string, number>;
+    darkMode: 'attribute' | 'class' | 'media';
+}
+declare const defaultTheme: ThemeConfig;
+declare function setTheme(theme: ThemeConfig): void;
+declare function getTheme(): 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;
+
+/**
+ * Reactive read of the global dark-mode store — works with or without a
+ * `<ThemeProvider>` mounted anywhere in the tree, since it subscribes to
+ * `darkModeStore.ts` directly. 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 useGlobalDarkMode(): boolean;
+
+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;
+}
+/**
+ * Native port of @kbach/react's `ThemeProvider` — a thin, OPTIONAL React
+ * Context wrapper around `darkModeStore.ts`'s single global store, not the
+ * source of truth itself. Because the store is global, MULTIPLE mounted
+ * providers share the exact same `mode`/`isDark` state rather than each
+ * getting their own scoped value — mounting more than one is very likely a
+ * mistake (each fighting over the same state via a different
+ * `defaultMode`), so this warns once in dev, matching the web version's
+ * identical guard.
+ */
+declare function ThemeProvider({ children, defaultMode }: ThemeProviderProps): react.JSX.Element;
+
+interface ThemeContextValue {
+    mode: ThemeMode;
+    isDark: boolean;
+    setMode: (mode: ThemeMode) => void;
+    toggle: () => void;
+}
+/**
+ * Requires a `<ThemeProvider>` ancestor — throws otherwise, since a
+ * component that destructures `{ mode, setMode }` genuinely needs Context
+ * (unlike a component that just wants the dark/light boolean, which should
+ * reach for `useGlobalDarkMode()` instead and never needs a provider at
+ * all).
+ */
+declare function useTheme(): ThemeContextValue;
+
+export { type ThemeConfig as T, type ThemeContextValue as a, type ThemeMode as b, ThemeProvider as c, type ThemeProviderProps as d, defaultTheme as e, getGlobalThemeMode as f, getGlobalDarkMode as g, getTheme as h, setTheme as i, subscribeGlobalDarkMode as j, useTheme as k, setGlobalThemeMode as s, toggleGlobalDarkMode as t, useGlobalDarkMode as u };

package/dist/ThemeContext-Dc5AC-m0.d.ts

@@ -0,0 +1,98 @@
+import * as react from 'react';
+import { ReactNode } from 'react';
+
+interface ThemeConfig {
+    /** Plain hex only, this pass — e.g. "blue-6" -> "#2563eb" */
+    colors: Record<string, string>;
+    spacing: Record<string, number>;
+    screens: Record<string, number>;
+    darkMode: 'attribute' | 'class' | 'media';
+}
+declare const defaultTheme: ThemeConfig;
+declare function setTheme(theme: ThemeConfig): void;
+declare function getTheme(): 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;
+
+/**
+ * Reactive read of the global dark-mode store — works with or without a
+ * `<ThemeProvider>` mounted anywhere in the tree, since it subscribes to
+ * `darkModeStore.ts` directly. 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 useGlobalDarkMode(): boolean;
+
+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;
+}
+/**
+ * Native port of @kbach/react's `ThemeProvider` — a thin, OPTIONAL React
+ * Context wrapper around `darkModeStore.ts`'s single global store, not the
+ * source of truth itself. Because the store is global, MULTIPLE mounted
+ * providers share the exact same `mode`/`isDark` state rather than each
+ * getting their own scoped value — mounting more than one is very likely a
+ * mistake (each fighting over the same state via a different
+ * `defaultMode`), so this warns once in dev, matching the web version's
+ * identical guard.
+ */
+declare function ThemeProvider({ children, defaultMode }: ThemeProviderProps): react.JSX.Element;
+
+interface ThemeContextValue {
+    mode: ThemeMode;
+    isDark: boolean;
+    setMode: (mode: ThemeMode) => void;
+    toggle: () => void;
+}
+/**
+ * Requires a `<ThemeProvider>` ancestor — throws otherwise, since a
+ * component that destructures `{ mode, setMode }` genuinely needs Context
+ * (unlike a component that just wants the dark/light boolean, which should
+ * reach for `useGlobalDarkMode()` instead and never needs a provider at
+ * all).
+ */
+declare function useTheme(): ThemeContextValue;
+
+export { type ThemeConfig as T, type ThemeContextValue as a, type ThemeMode as b, ThemeProvider as c, type ThemeProviderProps as d, defaultTheme as e, getGlobalThemeMode as f, getGlobalDarkMode as g, getTheme as h, setTheme as i, subscribeGlobalDarkMode as j, useTheme as k, setGlobalThemeMode as s, toggleGlobalDarkMode as t, useGlobalDarkMode as u };

package/dist/{chunk-AEVOM2NB.mjs → chunk-4BXM3QUV.mjs}

@@ -278,16 +278,49 @@ var PALETTE = {
 // src/theme.ts
 var defaultTheme = {
   colors: PALETTE,
+  // Real Tailwind's default spacing scale in full — every step is exactly
+  // `n * 4px`, including the fractional `.5` steps (`1.5` -> 6px, `2.5` ->
+  // 10px, `3.5` -> 14px) and the "px" literal (a bare 1px). Previously
+  // this only had {0,1,2,4,6,8} — a handful of spot-checked values, not
+  // the real scale — so anything else (`p-3`, `w-5`, `border-2`,
+  // `gap-10`, ...) silently failed to resolve. Mirrors @kbach/react's
+  // theme.ts exactly.
   spacing: {
-    // "0" is always a hardcoded zero in real Tailwind's own scale too,
-    // regardless of the base spacing unit — needed for `p-0`/`m-0`/etc.
-    // Mirrors the identical fix in @kbach/react's theme.ts.
     "0": 0,
+    "px": 1,
+    "0.5": 2,
     "1": 4,
+    "1.5": 6,
     "2": 8,
+    "2.5": 10,
+    "3": 12,
+    "3.5": 14,
     "4": 16,
+    "5": 20,
     "6": 24,
-    "8": 32
+    "7": 28,
+    "8": 32,
+    "9": 36,
+    "10": 40,
+    "11": 44,
+    "12": 48,
+    "14": 56,
+    "16": 64,
+    "20": 80,
+    "24": 96,
+    "28": 112,
+    "32": 128,
+    "36": 144,
+    "40": 160,
+    "44": 176,
+    "48": 192,
+    "52": 208,
+    "56": 224,
+    "60": 240,
+    "64": 256,
+    "72": 288,
+    "80": 320,
+    "96": 384
   },
   screens: {
     sm: 640,
@@ -311,61 +344,9 @@ function getThemeJson() {
   return activeThemeJson;
 }
 
-// src/darkModeStore.ts
-import { Appearance } from "react-native";
-var listeners = /* @__PURE__ */ new Set();
-function systemPrefersDark() {
-  return Appearance.getColorScheme() === "dark";
-}
-function resolveIsDark(m) {
-  return m === "system" ? systemPrefersDark() : m === "dark";
-}
-var mode = "system";
-var isDark = resolveIsDark(mode);
-var hasExplicitChoice = false;
-var subscription = Appearance.addChangeListener(({ colorScheme }) => {
-  if (mode !== "system") return;
-  isDark = colorScheme === "dark";
-  notify();
-});
-function notify() {
-  for (const listener of listeners) listener();
-}
-function getGlobalDarkMode() {
-  return isDark;
-}
-function getGlobalThemeMode() {
-  return mode;
-}
-function setGlobalThemeMode(nextMode) {
-  mode = nextMode;
-  isDark = resolveIsDark(nextMode);
-  hasExplicitChoice = true;
-  notify();
-}
-function toggleGlobalDarkMode() {
-  setGlobalThemeMode(isDark ? "light" : "dark");
-}
-function subscribeGlobalDarkMode(listener) {
-  listeners.add(listener);
-  return () => listeners.delete(listener);
-}
-function seedDefaultMode(fallback) {
-  if (hasExplicitChoice || mode === fallback) return;
-  mode = fallback;
-  isDark = resolveIsDark(fallback);
-  notify();
-}
-
 export {
   defaultTheme,
   setTheme,
   getTheme,
-  getThemeJson,
-  getGlobalDarkMode,
-  getGlobalThemeMode,
-  setGlobalThemeMode,
-  toggleGlobalDarkMode,
-  subscribeGlobalDarkMode,
-  seedDefaultMode
+  getThemeJson
 };

package/dist/{chunk-4KCCEMEN.mjs → chunk-CGU7UM2F.mjs}

@@ -5,7 +5,7 @@ import {
   setGlobalThemeMode,
   subscribeGlobalDarkMode,
   toggleGlobalDarkMode
-} from "./chunk-AEVOM2NB.mjs";
+} from "./chunk-Z664AKW7.mjs";
 
 // src/useGlobalDarkMode.ts
 import { useSyncExternalStore } from "react";