@kbach/react-native 1.0.0-beta.2 → 1.0.0-beta.20

package/README.md

@@ -2,33 +2,19 @@
 
 Kbach's utility-class styling engine for React Native — the same class
 names as [`@kbach/react`](https://www.npmjs.com/package/@kbach/react),
-resolved to a real `StyleSheet`-ready style object instead of injected CSS.
+resolved to a `StyleSheet`-ready style object instead of injected CSS.
 
-> **Beta, Android-only.** Resolution runs through a Kotlin/JNI TurboModule
-> calling the same Rust core `@kbach/react` uses, so class semantics stay
-> identical across web and native. The native module ships prebuilt (see
-> Setup below) — no Rust toolchain or manual native wiring required — but
-> there's no iOS bridge yet.
+> Beta. Native is Android-only (no iOS bridge yet). Ships a prebuilt native
+> module — no Rust toolchain or manual native wiring required.
 
-## Setup
+## Install
 
 ```sh
 npm install @kbach/react-native
 ```
 
-That pulls in [`@kbach/android`](https://www.npmjs.com/package/@kbach/android)
-too — the actual native module — as a real dependency. 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.
-
 ### React Native CLI
 
-Add the Babel plugin so your app's JSX routes through Kbach's JSX runtime
-instead of `react/jsx-runtime`:
-
 ```js
 // babel.config.js
 module.exports = {
@@ -37,104 +23,251 @@ module.exports = {
 };
 ```
 
-Then rebuild the Android app (`npm run android`, or a clean Gradle build if
-you're re-running one that's already built) so Gradle picks up the new
-native module. See `apps/native-sandbox` in the
-[repo](https://github.com/semsakadanupol/kbach) for a full working
-reference project, including the Metro config a monorepo setup like this
-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).
+Rebuild the Android app afterward so Gradle picks up the native module.
+
+### Expo Go
+
+Works out of the box — no prebuild, no dev client, nothing to configure.
+Expo Go can't load third-party native code, so this falls back to a pure-JS
+engine automatically. Covers layout, spacing, border/radius, plain colors,
+font-weight, text-transform/decoration, line-height, letter-spacing, and
+shadows. Doesn't cover grid, transforms, filters, gradients, or DOM-only
+typography — same scope native itself excludes.
 
-### Expo
+### Expo (dev client / prebuild)
 
-**Expo Go doesn't work** — it's a fixed pre-built binary with no way to
-load a custom native module like `@kbach/android`. You need a **dev
-client** instead (a custom build of your app with this module baked in) —
-functionally the same "real native project" setup as the CLI path above,
-just generated and driven through Expo's own tooling:
+Gets you the full native engine instead of the JS fallback:
 
 ```js
 // babel.config.js
 module.exports = {
-  presets: ['babel-preset-expo'], // not '@react-native/babel-preset'
+  presets: ['babel-preset-expo'],
   plugins: ['@kbach/react-native/babel-plugin'],
 };
 ```
 
 ```sh
-npx expo prebuild    # generates android/ (and ios/, which this package doesn't support yet)
-npx expo run:android # builds and installs a dev client with the native module included
+npx expo prebuild
+npx expo run:android
 ```
 
-Also requires the New Architecture enabled (Expo's default in current SDK
-versions) — `@kbach/android` is a TurboModule, which doesn't exist under
-the legacy bridge at all. If you're on an older SDK/config with the New
-Architecture off, turn it on in `app.json`
-(`"newArchEnabled": true` under `expo`) before prebuilding.
-
-EAS Build works the same way — it runs the same `prebuild` step, so no
-extra configuration beyond the two steps above.
-
-## What this is
-
-- A JSX runtime (`@kbach/react-native/jsx-runtime`) that intercepts
-  `className`/`kb` props on every element and calls into the native bridge
-  to resolve them to a style object, synchronously, on every render.
-- 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.
-- `setTheme()`/`getTheme()` for customizing the color palette and spacing
-  scale — the same `ThemeConfig` shape `@kbach/react` uses, kept as an
-  independent type here so a native-only project isn't forced to depend on
-  a web-oriented package.
-- `shadow-*` resolves to real native shadows — iOS's discrete
-  `shadowColor`/`shadowOffset`/`shadowOpacity`/`shadowRadius` and Android's
-  `elevation`, both derived from the same named tiers (`sm`/`DEFAULT`/`md`/
-  `lg`/`xl`/`2xl`) `@kbach/react`'s CSS `box-shadow` scale uses — one class
-  produces a real shadow on both platforms. `shadow-inner` and arbitrary
-  `shadow-[...]` values aren't supported — neither platform's native shadow
-  API can express an inset shadow, and an arbitrary value is a raw CSS
-  string with no mechanical translation into discrete native props.
+Requires the New Architecture enabled (`"newArchEnabled": true` in
+`app.json`, on by default in current Expo SDKs). EAS Build works the same
+way, no extra config.
 
-## Dark mode
+### Expo Web
+
+Works out of the box — resolves through the same real-CSS engine
+`@kbach/react` uses on the DOM, with full modifier support (`hover:`,
+`focus:`, `group-hover:`, container queries, etc.), not just the
+`dark:`/`active:`/responsive subset native supports.
 
-Works standalone, with zero provider — same architecture as `@kbach/react`:
+**Static rendering (SSR) caveat:** `dark:`/responsive classes on content
+that's part of the initial pre-rendered HTML resolve against the *server*,
+not the visiting browser — so a user in dark mode can briefly see the light
+version on first paint. Defer preference-dependent classes until mounted:
 
 ```tsx
-import { useGlobalDarkMode, toggleGlobalDarkMode } from '@kbach/react-native';
+const [mounted, setMounted] = useState(false);
+useEffect(() => setMounted(true), []);
 
-function ThemeToggle() {
-  const isDark = useGlobalDarkMode();
-  return <Pressable onPress={toggleGlobalDarkMode}><Text>{isDark ? 'Dark' : 'Light'}</Text></Pressable>;
-}
+<View className={mounted ? 'bg-gray-1 dark:bg-gray-12' : 'bg-gray-1'} />;
+```
+
+### Monorepo installs (npm/yarn/pnpm workspaces)
+
+If your app lives in a monorepo where `@kbach/react-native` is a workspace
+package (a `file:`/`link:` dependency, or hoisted rather than nested), watch
+for **two physical copies of `react-native`/`react`** ending up in your
+dependency tree — one this package would otherwise resolve up to from its
+own directory, and a different one your app's own files resolve to. Metro
+walks `node_modules` hierarchically per-file, so it can silently hand two
+different files two different copies of the *same* module, each with its
+own separate module state.
+
+This isn't hypothetical: it's the root cause of a real dark-mode bug this
+package shipped and fixed — `useColorScheme()`/`Appearance` in one copy
+never saw changes made through the other, so an explicit theme toggle
+appeared to do nothing. The fix is a Metro config override that forces a
+single instance, **required in your app**, not something this package can
+do on your behalf from inside `node_modules`:
+
+```js
+// metro.config.js
+const path = require('path');
+// React Native CLI: const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');
+// Expo:              const { getDefaultConfig } = require('expo/metro-config');
+
+const projectRoot = __dirname;
+const workspaceRoot = path.resolve(projectRoot, '../..'); // -> your monorepo root
+
+const config = getDefaultConfig(projectRoot);
+config.watchFolders = [workspaceRoot];
+
+const forcedSingleInstance = {
+  'react-native': path.resolve(projectRoot, 'node_modules/react-native'),
+  react: path.resolve(projectRoot, 'node_modules/react'),
+};
+const defaultResolveRequest = config.resolver.resolveRequest;
+config.resolver.resolveRequest = (context, moduleName, platform) => {
+  if (Object.prototype.hasOwnProperty.call(forcedSingleInstance, moduleName)) {
+    return { type: 'sourceFile', filePath: require.resolve(forcedSingleInstance[moduleName]) };
+  }
+  return defaultResolveRequest
+    ? defaultResolveRequest(context, moduleName, platform)
+    : context.resolveRequest(context, moduleName, platform);
+};
+
+module.exports = config; // (React Native CLI: mergeConfig(getDefaultConfig(projectRoot), config))
 ```
 
-Or the optional `<ThemeProvider>` / `useTheme()` pair, reading and writing
-the exact same global store:
+A single, non-monorepo `npm install` never hits this — only relevant if your
+app and `@kbach/react-native` share a workspace root.
+
+## Dark mode
 
 ```tsx
-import { ThemeProvider, useTheme } from '@kbach/react-native';
+import { useTheme } from '@kbach/react-native';
 
-function Toggle() {
+function ThemeToggle() {
   const { mode, isDark, setMode, toggle } = useTheme();
   return <Pressable onPress={toggle}><Text>{mode}</Text></Pressable>;
 }
+```
+
+Works anywhere, no provider needed. `<ThemeProvider defaultMode="dark">` is
+optional, for seeding a startup default. Outside React, use
+`getGlobalDarkMode()`/`toggleGlobalDarkMode()` instead.
+
+Follows the OS setting live until overridden, and isn't persisted across
+app launches (no built-in storage dependency). To persist, read your own
+storage at startup and call `setGlobalThemeMode()` before your first render.
+
+## Reading colors as values
+
+For anywhere you need a real color, not a `className` — a chart prop, a
+native shadow color:
+
+```tsx
+import { useColors } from '@kbach/react-native';
+
+const colors = useColors();
+colors.blue[6];       // '#2563eb' — static, same value in both modes
+colors.blue['6/50'];  // same, at 50% opacity
+```
 
-<ThemeProvider defaultMode="system">
-  <Toggle />
-</ThemeProvider>;
+Any color can be defined in the theme as a plain string (static) or a
+`{ light, dark }` pair — fully manual, resolved per the current dark-mode
+state:
+
+```ts
+setTheme({
+  ...defaultTheme,
+  colors: { ...defaultTheme.colors, brand: { light: '#2563eb', dark: '#93c5fd' } },
+});
+```
+
+A shade-family lookup (`colors.blue[n]`) auto-mirrors to shade `13 - n` in
+dark mode — this palette's own convention is 1 = lightest, 12 = darkest, so
+that's the same visual weight relative to its own background, no manual
+`colors.blue[isDark ? 7 : 6]` needed.
+
+## Arbitrary math: `calc()`, `clamp()`, `min()`, `max()`
+
+```tsx
+<View className="p-[calc(16px+8px)]" />       // -> padding: 24
+<View className="w-[clamp(1rem,2rem,3rem)]" /> // -> width: 32
+```
+
+Resolves at **build/resolve time**, not runtime — every operand must be a
+constant `px`/`rem` length (or a bare number). This works because native has
+no CSS engine to evaluate a real `calc()` string at paint time, so the only
+way to support it at all is to compute the answer ourselves.
+
+A **viewport-relative** expression (`calc(10vw+8px)`) can't be reduced this
+way — no such unit exists on native at all. It already works fine on web
+(real CSS); on native the declaration is dropped and a `console.warn`
+explains why (dev builds only).
+
+**Percentage-relative width/height** (`calc(100%-3rem)`, `calc(50%+16px)`)
+IS supported, differently: since native has no way to know "100% of what"
+ahead of time, this measures the element's own real layout instead —
+
+```tsx
+<View className="w-[calc(100%_-_3rem)]" />
+```
+
+Renders once at a plain `100%` (a real RN percentage, resolved correctly by
+RN's own layout engine against the parent) purely to trigger a layout
+event, then immediately corrects to the actual computed number once
+measured — a genuine one-frame measure-then-snap, not instant math like the
+constant-only case above, and it keeps re-measuring on every layout (screen
+rotation, parent resize, ...) rather than freezing after the first value.
+Scoped to exactly one percentage term plus one constant term on `width`/
+`height` only — `calc(50%-50%)`, other properties, or anything with `*`/`/`
+falls through to the same drop-and-warn behavior as before.
+
+**Arbitrary values can't contain literal spaces** — this is a pre-existing
+rule (real Tailwind has the same one), not specific to `calc()`: a space
+inside `[...]` is indistinguishable from the whitespace that separates
+class tokens in the first place, so `w-[calc(100% - 3rem)]` silently splits
+into three broken tokens before `calc()` is ever even recognized. Write
+`w-[calc(100%_-_3rem)]` (underscores) instead — this is exactly what the
+unknown-class warning below is for: it'll tell you when this happens.
+
+## Unknown-class warnings (typo detection)
+
+```tsx
+<View className="flexx-center" /> // real Kbach classes never have to guess — a typo warns
+```
+
+```
+Kbach: "flexx-center" doesn't match any known Kbach utility — typo? (skipped) (from className "flexx-center")
+```
+
+On native/dev-client builds, a class that doesn't match *any* Kbach
+utility on *any* platform gets a `console.warn` (dev builds only, printed
+once per unique message) instead of silently doing nothing — the same
+signal `@kbach/react`'s Vite plugin already gives you at build time on
+web, just at resolve time here instead. A real utility this engine simply
+doesn't support on native yet (`grid-cols-3`, `scale-150`, `blur`, ...)
+never warns — that's an intentional, documented platform gap (see
+`resolve_style.rs`'s own doc comment), not a typo, so it stays silent the
+same way it always has.
+
+Not available in Expo Go's pure-JS fallback engine today — that engine has
+no web-shaped resolver to check "is this a real Kbach utility at all"
+against, only the (smaller) native-supported subset, so it can't
+distinguish a genuine typo from a real-but-native-unsupported class
+without a much larger port. A real dev-client/CLI build always gets this
+check.
+
+## Dynamic tokens
+
+The native counterpart to a real CSS custom property — `var(--x)` already
+works in a `className` on Expo Web with zero help from this package (real
+CSS, resolved by the browser). This gives native the same className syntax:
+
+```tsx
+import { setDynamicToken, useDynamicToken } from '@kbach/react-native';
+
+setDynamicToken('sidebar-width', '240px'); // updates every subscribed element, on both platforms
+<View className="w-[var(--sidebar-width)]" />
+
+// Reading the raw value in JS, reactively:
+function Sidebar() {
+  const width = useDynamicToken('sidebar-width'); // '240px' | undefined
+}
 ```
 
-By default the mode follows the OS `Appearance` setting live until you
-explicitly override it — and **isn't persisted across app launches**.
-There's no React-Native-builtin equivalent of `localStorage`, and 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. If you want persistence, read your own storage at
-startup and call `setGlobalThemeMode()` with the result before your first
-render — the same "seed once" shape `<ThemeProvider defaultMode>` itself
-uses internally.
+On web, `setDynamicToken` writes the real CSS custom property to the DOM —
+every element using it repaints instantly via the browser's own CSS engine,
+no React re-render involved. On native, the className is substituted with
+the token's current value before every resolve, and an element referencing
+a token re-renders/repaints on its own when that specific token changes
+(same `key`-remount mechanism `dark:` and `sm:`/`md:`/... already use — see
+`jsxRuntimeCore.ts`'s own doc comments). An unregistered token name falls
+through to the same native invalid-value warning above.
 
 ## License
 

package/android/build.gradle

@@ -0,0 +1,36 @@
+apply plugin: "com.android.library"
+apply plugin: "org.jetbrains.kotlin.android"
+apply plugin: "com.facebook.react"
+
+def getExtOrDefault(name) {
+    return rootProject.ext.has(name) ? rootProject.ext.get(name) : null
+}
+
+android {
+    // NOT "com.kbachnative" — that's the app module's own namespace (Phase 5
+    // deliberately made the app's package match KbachModule's Kotlin package
+    // for simpler JNI symbol names), and AGP requires unique namespaces per
+    // module. This is purely a Gradle build-identity value, separate from
+    // the actual `package com.kbachnative` declared in the .kt files below —
+    // JNI symbol resolution depends on that Kotlin package, not this.
+    namespace "com.kbachnative.nativemodule"
+    compileSdkVersion getExtOrDefault("compileSdkVersion")
+
+    defaultConfig {
+        minSdkVersion getExtOrDefault("minSdkVersion")
+        targetSdkVersion getExtOrDefault("targetSdkVersion")
+    }
+}
+
+repositories {
+    google()
+    maven {
+        // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm.
+        url "$rootDir/../node_modules/react-native/android"
+    }
+    mavenCentral()
+}
+
+dependencies {
+    implementation "com.facebook.react:react-native:+"
+}

package/android/src/main/AndroidManifest.xml

@@ -0,0 +1,14 @@
+<!--
+  Deliberately NO `package="..."` attribute here, even though this
+  module's Kotlin package (com.kbachnative, see KbachModule.kt) differs
+  from its Gradle build.gradle `namespace` (com.kbachnative.nativemodule)
+  — adding one here to help React Native's autolinking guess the right
+  Kotlin package (see react-native.config.js at this package's root, which
+  fixes that instead) breaks the actual Gradle build on AGP 9+: it now
+  hard-errors ("Setting the namespace via the package attribute in the
+  source AndroidManifest.xml is no longer supported") whenever the
+  manifest's package doesn't match the namespace exactly. If you're
+  tempted to add one back to fix an autolinking symbol-resolution error,
+  fix react-native.config.js's packageImportPath/packageInstance instead.
+-->
+<manifest xmlns:android="http://schemas.android.com/apk/res/android" />

package/android/src/main/java/com/kbachnative/KbachModule.kt

@@ -0,0 +1,83 @@
+package com.kbachnative
+
+import com.facebook.react.bridge.ReactApplicationContext
+
+/**
+ * Bridges to the same Rust core engine every other Kbach platform uses
+ * (packages/core-engine) — via JNI here instead of WASM. The native
+ * `generateCss`/`resolveStyle` externs below (in the companion object) must
+ * match `Java_com_kbachnative_KbachModule_generateCss`/`resolveStyle`'s
+ * signatures exactly (packages/core-engine/src/jni_bridge.rs): STATIC
+ * native methods (hence @JvmStatic in a companion object, not instance
+ * methods — the Rust side takes JClass, not JObject, as its second
+ * parameter).
+ *
+ * TurboModule since Phase 13 (was the legacy bridge's
+ * `isBlockingSynchronousMethod` support directly on `ReactContextBaseJavaModule`
+ * before) — extends the Codegen-generated `NativeKbachModuleSpec`
+ * (packages/react-native/specs/NativeKbachModule.ts -> this package's own
+ * codegenConfig in package.json, discovered via autolinking ->
+ * android/build/generated/source/codegen/java/com/kbachnative/NativeKbachModuleSpec.java),
+ * which already provides `getName()` and declares `generateCss`/`resolveStyle`
+ * as abstract `@ReactMethod(isBlockingSynchronousMethod = true)` methods —
+ * Codegen still routes a synchronously-returning TurboModule method through
+ * that same Android bridge mechanism; the real gain here is JSI-backed
+ * dispatch + build-time type checking against the JS spec, not the removal
+ * of `isBlockingSynchronousMethod` as a concept.
+ *
+ * The companion's JNI externs are named `nativeGenerateCss`/`nativeResolveStyle`
+ * — NOT the same names as the spec's `generateCss`/`resolveStyle` overrides.
+ * Tried keeping identical names first (disambiguated via an explicit
+ * `Companion.generateCss(...)` qualifier) since that would've meant zero
+ * Rust changes, but that fails to compile: `@JvmStatic` duplicates each
+ * companion function directly onto the outer class for Java-interop
+ * purposes, which collides at the JVM bytecode level with the identically-
+ * named, identically-shaped instance override ("platform declaration
+ * clash"), regardless of how the Kotlin-source call site is qualified. The
+ * rename requires matching `Java_com_kbachnative_KbachModule_nativeGenerateCss`/
+ * `nativeResolveStyle` `#[no_mangle]` export names in
+ * packages/core-engine/src/jni_bridge.rs — JNI's implicit symbol linking
+ * binds by the extern's own method name, not by whatever calls it.
+ *
+ * Moved here from apps/native-sandbox/android/app in Phase 13 — Android
+ * autolinking only discovers native modules from npm dependencies with
+ * their own `android/` folder, never from native code declared directly
+ * inside the app itself, so `KbachModule` had to become a real (locally
+ * `file:`-linked) package to be found by `TurboModuleRegistry.getEnforcing`.
+ * Originally that "real package" was a separate `@kbach/android` npm
+ * package; later folded directly into `@kbach/react-native` (this
+ * package's own `android/` folder, sibling to its `src/`) once it became
+ * clear the same autolinking requirement is satisfied just as well by a
+ * SINGLE npm package containing both JS and native code — the same layout
+ * react-native-safe-area-context itself uses — so consumers only ever run
+ * one `npm install @kbach/react-native`, not two.
+ */
+class KbachModule(reactContext: ReactApplicationContext) : NativeKbachModuleSpec(reactContext) {
+
+    companion object {
+        init {
+            System.loadLibrary("kbach_core_engine")
+        }
+
+        @JvmStatic
+        external fun nativeGenerateCss(classString: String, themeJson: String): String
+
+        @JvmStatic
+        external fun nativeResolveStyle(classString: String, themeJson: String, colorScheme: String, pressed: Boolean, width: Double): String
+    }
+
+    override fun generateCss(classString: String, themeJson: String): String {
+        return nativeGenerateCss(classString, themeJson)
+    }
+
+    /**
+     * `colorScheme` ("light"/"dark", from Appearance.getColorScheme() on the
+     * JS side) gates whether `dark:` declarations are applied; `pressed`
+     * (only ever true when the caller is RN's Pressable) gates `active:`;
+     * `width` (the JS side's current `Dimensions.get('window').width`) gates
+     * `sm:`/`md:`/`lg:`/`xl:`/`2xl:` against the theme's `screens` scale.
+     */
+    override fun resolveStyle(classString: String, themeJson: String, colorScheme: String, pressed: Boolean, width: Double): String {
+        return nativeResolveStyle(classString, themeJson, colorScheme, pressed, width)
+    }
+}

package/android/src/main/java/com/kbachnative/KbachPackage.kt

@@ -0,0 +1,54 @@
+package com.kbachnative
+
+import com.facebook.react.BaseReactPackage
+import com.facebook.react.bridge.NativeModule
+import com.facebook.react.bridge.ReactApplicationContext
+import com.facebook.react.module.model.ReactModuleInfo
+import com.facebook.react.module.model.ReactModuleInfoProvider
+import com.facebook.react.uimanager.ViewManager
+
+/**
+ * `BaseReactPackage` (not plain `ReactPackage`) since Phase 13's TurboModule
+ * migration — a plain `ReactPackage`'s `createNativeModules()`-provided
+ * modules stay visible to the legacy `NativeModules` interop but are never
+ * consulted by `TurboModuleRegistry`'s resolution path, which only walks
+ * packages that can answer `getModule(name, ...)` directly. Modeled on
+ * react-native-safe-area-context's own `SafeAreaContextPackage.kt` (a real,
+ * New-Architecture-compatible package already in this project's
+ * dependencies) rather than reflection over a `@ReactModule` annotation —
+ * KbachModule doesn't have one, and there's only ever this one module, so
+ * building its `ReactModuleInfo` directly is simpler than adding an
+ * annotation just to read it back via reflection.
+ *
+ * Auto-discovered via Android autolinking, not manually registered in
+ * apps/native-sandbox's MainApplication.kt — same as SafeAreaContextPackage
+ * already was, and the entire reason this module became a real npm package
+ * with its own `android/` folder (this one — `@kbach/react-native` itself,
+ * see KbachModule.kt's own doc comment) in Phase 13 rather than living
+ * inside the app.
+ */
+class KbachPackage : BaseReactPackage() {
+    override fun getModule(name: String, reactContext: ReactApplicationContext): NativeModule? {
+        return if (name == NativeKbachModuleSpec.NAME) KbachModule(reactContext) else null
+    }
+
+    override fun getReactModuleInfoProvider(): ReactModuleInfoProvider {
+        return ReactModuleInfoProvider {
+            mapOf(
+                NativeKbachModuleSpec.NAME to
+                    ReactModuleInfo(
+                        NativeKbachModuleSpec.NAME,
+                        KbachModule::class.java.name,
+                        false, // canOverrideExistingModule
+                        false, // needsEagerInit
+                        false, // isCxxModule
+                        true, // isTurboModule
+                    )
+            )
+        }
+    }
+
+    override fun createViewManagers(reactContext: ReactApplicationContext): List<ViewManager<*, *>> {
+        return emptyList()
+    }
+}

package/dist/chunk-45GOGUHJ.mjs

@@ -0,0 +1,107 @@
+import {
+  getTheme
+} from "./chunk-OGFB3OXS.mjs";
+
+// 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";
+}
+function applyToDom(dark) {
+  if (typeof document === "undefined") return;
+  const root = document.documentElement;
+  const strategy = getTheme().darkMode;
+  if (strategy === "class") {
+    root.classList.toggle("dark", dark);
+    root.classList.toggle("light", !dark);
+  } else if (strategy === "attribute") {
+    root.setAttribute("data-theme", dark ? "dark" : "light");
+  }
+}
+var mode = "system";
+var isDark = resolveIsDark(mode);
+applyToDom(isDark);
+var hasExplicitChoice = false;
+var subscription = Appearance.addChangeListener(({ colorScheme }) => {
+  if (mode !== "system") return;
+  isDark = colorScheme === "dark";
+  applyToDom(isDark);
+  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;
+  applyToDom(isDark);
+  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);
+  applyToDom(isDark);
+  notify();
+}
+
+// src/dynamicTokens.ts
+var tokens = /* @__PURE__ */ new Map();
+var listeners2 = /* @__PURE__ */ new Set();
+var version = 0;
+function applyToDom2(name, value) {
+  if (typeof document === "undefined") return;
+  document.documentElement.style.setProperty(`--${name}`, value);
+}
+function notify2() {
+  version++;
+  for (const listener of listeners2) listener();
+}
+function setDynamicToken(name, value) {
+  tokens.set(name, value);
+  applyToDom2(name, value);
+  notify2();
+}
+function getDynamicToken(name) {
+  return tokens.get(name);
+}
+function deleteDynamicToken(name) {
+  if (!tokens.delete(name)) return;
+  if (typeof document !== "undefined") document.documentElement.style.removeProperty(`--${name}`);
+  notify2();
+}
+function subscribeDynamicTokens(listener) {
+  listeners2.add(listener);
+  return () => listeners2.delete(listener);
+}
+
+export {
+  getGlobalDarkMode,
+  getGlobalThemeMode,
+  setGlobalThemeMode,
+  toggleGlobalDarkMode,
+  subscribeGlobalDarkMode,
+  seedDefaultMode,
+  setDynamicToken,
+  getDynamicToken,
+  deleteDynamicToken,
+  subscribeDynamicTokens
+};