@oxyhq/bloom 0.7.4 → 0.7.6

package/lib/typescript/commonjs/theme/native-root-vars.d.ts

@@ -1,94 +1,34 @@
 import { type AppColorName } from './color-presets';
 /**
- * Publish the active color preset's CSS custom properties into react-native-css's
- * GLOBAL root-variable family so they reach the ENTIRE native app tree — including
- * content rendered outside the React subtree of `BloomThemeProvider`: expo-router
- * navigator screens, `Portal`s, `Dialog`/`BottomSheet` overlays, and any other host
- * that paints through a separate React root.
- *
- * Why a global write is required (native only)
- * --------------------------------------------
- * react-native-css resolves a `var(--x)` reference (its `varResolver`) in this order:
- *   1. `name in inheritedVariables`  — the React-context-inherited vars. This is what
- *      `VariableContextProvider` populates, but it is React-context-scoped, so it only
- *      reaches *direct descendants* of the provider in the React tree.
- *   2. `inlineVariables[name]`        — same-component inline vars.
- *   3. `variables[name]`             — resolved inherited vars.
- *   4. `universalVariables(name)`    — a GLOBAL observable family.
- *   5. `rootVariables(name)`         — a GLOBAL observable family.
- *   6. the declared fallback.
- *
- * `BloomThemeProvider`'s `VariableContextProvider` only feeds path #1, so the navigator
- * host and every portal/modal — which render outside that subtree — never see the
- * preset vars and fall through to `rootVariables`/`universalVariables`. By default those
- * families hold only react-native-css's own `__rn-css-rem`/`__rn-css-color` entries
- * (Bloom's `global.css` defines the `hsl(var(--primary))` indirection but not the HSL
- * triples themselves — those are injected at runtime), so the whole tree below the
- * navigator renders monochrome. Writing the vars into `rootVariables` here is the
- * exact same mechanism react-native-css uses for compiled `:root {}` / `@theme` vars
- * (`StyleCollection.inject` does `rootVariables(name).set(valueArray)`), so portaled
- * content resolves the palette identically regardless of React-tree position.
- *
- * The raw tokens are written as HSL triples (`primary: '205 87% 53%'`) and the
- * resolved Tailwind v4 `--color-*` vars as sRGB `rgb(...)` (`color-primary:
- * 'rgb(31 153 239)'`) — the latter so `color-mix`-based alpha utilities resolve
- * on native (see `getPresetVars` / `hslTripletToRgb`).
- *
- * Why a STATIC `import`, not a runtime `require` (critical)
- * ---------------------------------------------------------
- * react-native-css@3.0.7 ships both a `dist/commonjs` and a `dist/module` build, and
- * Metro bundles BOTH. In `native-internal/root.js` the variable families are plain
- * module-local consts — NOT `globalThis`-guarded the way `StyleCollection` is — so the
- * commonjs `root.js` and the module `root.js` each instantiate their OWN separate
- * `rootVariables` family. The react-native-css renderer (`react-native-css/src/components/View.tsx`
- * → `varResolver`) imports its `root.js` via ESM `import`, i.e. the MODULE build. A
- * runtime `require('react-native-css/native-internal')` resolves the package's `require`
- * export condition → the COMMONJS build → a DIFFERENT family the renderer never
- * subscribes to, so the writes are a silent no-op on device. A static top-level
- * `import` resolves the `import` condition → the MODULE build → the renderer's instance.
- *
- * This plain file is the NATIVE/default variant (Metro selects it on iOS/Android,
- * which have no `.native` override here); the web variant lives in the sibling
- * `native-root-vars.web.ts` no-op, which web bundlers pick over this one. So the
- * static `react-native-css/native-internal` import below is never pulled into a web
- * bundle — only into native. This mirrors Bloom's existing platform-split convention
- * (`color-scope/index.tsx` + `color-scope/index.web.tsx`, `FontLoader.native.tsx`).
- *
- * Keying contract (verified against react-native-css@3.0.7)
- * ---------------------------------------------------------
- * The `rootVariables` family is keyed by the BARE variable name, WITHOUT the leading
- * `--`. The compiler strips it uniformly: a `:root { --primary: ... }` declaration is
- * stored via `rule.v.push([property.slice(2), value])` then routed into
- * `shared.rootVariables[name]`, and `@property --x` goes through
- * `name.startsWith("--") ? name.slice(2) : name`. The lookup side matches: a `var(--x)`
- * reference compiles to `[{}, "var", ident.slice(2)]`, so `varResolver` looks up the
- * bare name. `buildScopeVars` returns keys WITH the `--` prefix, so we strip it before
- * writing each entry.
- *
- * Value shape
- * -----------
- * Each entry is a `VariableValue[]` — an array of `[value, mediaCondition?]` tuples.
- * Bloom's preset vars are unconditional, so each is a single-element `[[value]]`, e.g.
- * `rootVariables('primary').set([['205 87% 53%']])`. This is the same shape the compiler
- * emits for unconditional `:root` vars.
- *
- * This is native-only and additive: the `VariableContextProvider` wrapper stays (it is
- * the correct, scoped mechanism for `BloomColorScope` subtree overrides and harmlessly
- * covers direct descendants). The web fork (`native-root-vars.web.ts`) no-ops — web
- * writes the same vars to `document.documentElement` via `applyColorPresetVars`.
- */
-/**
- * Write the preset's CSS vars to react-native-css's global `rootVariables` family
- * so the whole native tree (navigator screens + portals/modals/bottom-sheets)
- * resolves the active palette.
- *
- * Each `.set` notifies its own observers synchronously (react-native-css only
- * batches notifications inside its own `StyleCollection.inject`; outside it,
- * `observableBatch.current` is unset so every `.set` runs observers immediately),
- * so sequential writes correctly trigger a re-render when the preset/mode changes.
- *
- * Defensive guard: if a host ships a react-native-css build that doesn't expose
- * `rootVariables` as a callable (it always does on @3), we bail rather than throw.
+ * Platform-neutral DEFAULT variant of `applyNativeRootVars` — a no-op.
+ *
+ * This is the file resolved by every bundler / type-checker that does NOT do
+ * React Native's platform-extension resolution:
+ *   - a consumer's `tsc` (resolving Bloom's `"react-native"` -> `./src/...` source
+ *     export condition: `theme/index.ts` -> `BloomThemeProvider` -> this import);
+ *   - non-Metro web bundlers (Vite/Rolldown, webpack) resolving the package
+ *     `exports` `import`/`require` conditions to `lib/.../native-root-vars.js`.
+ *
+ * It deliberately does NOT import `react-native-css/native-internal`. That subpath
+ * is native-only: it has no web build, and react-native-css is not even a Bloom
+ * dependency. Statically importing it from a file a web bundler resolves breaks
+ * module resolution outright (the original report: `Rolldown failed to resolve
+ * import "react-native-css/native-internal" from .../native-root-vars.js`).
+ * Importing it from a file a consumer's `tsc` resolves breaks type-check (TS2307).
+ *
+ * Confining the real implementation (and that import) to the `.native` sibling —
+ * `native-root-vars.native.ts`, which ONLY Metro selects — keeps both web bundling
+ * AND downstream `tsc` green, while native still publishes the preset vars into
+ * react-native-css's GLOBAL `rootVariables` family so the whole native tree
+ * (navigator screens + portals/modals) resolves the palette.
+ *
+ * The other variants:
+ *   - `native-root-vars.native.ts` — iOS/Android (Metro), the real implementation;
+ *   - `native-root-vars.web.ts` — web, also a no-op (web writes the same vars to
+ *     `document.documentElement` via `applyColorPresetVars` instead).
+ *
+ * The signature is intentionally identical to those variants so the import site in
+ * `BloomThemeProvider` is platform-agnostic.
  */
-export declare function applyNativeRootVars(colorPreset: AppColorName, mode: 'light' | 'dark'): void;
+export declare function applyNativeRootVars(_colorPreset: AppColorName, _mode: 'light' | 'dark'): void;
 //# sourceMappingURL=native-root-vars.d.ts.map

package/lib/typescript/commonjs/theme/native-root-vars.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"native-root-vars.d.ts","sourceRoot":"","sources":["../../../../src/theme/native-root-vars.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,KAAK,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAEpD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AAEH;;;;;;;;;;;;GAYG;AACH,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,YAAY,EAAE,IAAI,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAS3F"}
+{"version":3,"file":"native-root-vars.d.ts","sourceRoot":"","sources":["../../../../src/theme/native-root-vars.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAEpD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAgB,mBAAmB,CAAC,YAAY,EAAE,YAAY,EAAE,KAAK,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAG7F"}

package/lib/typescript/commonjs/theme/native-root-vars.native.d.ts

@@ -0,0 +1,94 @@
+import { type AppColorName } from './color-presets';
+/**
+ * Publish the active color preset's CSS custom properties into react-native-css's
+ * GLOBAL root-variable family so they reach the ENTIRE native app tree — including
+ * content rendered outside the React subtree of `BloomThemeProvider`: expo-router
+ * navigator screens, `Portal`s, `Dialog`/`BottomSheet` overlays, and any other host
+ * that paints through a separate React root.
+ *
+ * Why a global write is required (native only)
+ * --------------------------------------------
+ * react-native-css resolves a `var(--x)` reference (its `varResolver`) in this order:
+ *   1. `name in inheritedVariables`  — the React-context-inherited vars. This is what
+ *      `VariableContextProvider` populates, but it is React-context-scoped, so it only
+ *      reaches *direct descendants* of the provider in the React tree.
+ *   2. `inlineVariables[name]`        — same-component inline vars.
+ *   3. `variables[name]`             — resolved inherited vars.
+ *   4. `universalVariables(name)`    — a GLOBAL observable family.
+ *   5. `rootVariables(name)`         — a GLOBAL observable family.
+ *   6. the declared fallback.
+ *
+ * `BloomThemeProvider`'s `VariableContextProvider` only feeds path #1, so the navigator
+ * host and every portal/modal — which render outside that subtree — never see the
+ * preset vars and fall through to `rootVariables`/`universalVariables`. By default those
+ * families hold only react-native-css's own `__rn-css-rem`/`__rn-css-color` entries
+ * (Bloom's `global.css` defines the `hsl(var(--primary))` indirection but not the HSL
+ * triples themselves — those are injected at runtime), so the whole tree below the
+ * navigator renders monochrome. Writing the vars into `rootVariables` here is the
+ * exact same mechanism react-native-css uses for compiled `:root {}` / `@theme` vars
+ * (`StyleCollection.inject` does `rootVariables(name).set(valueArray)`), so portaled
+ * content resolves the palette identically regardless of React-tree position.
+ *
+ * The raw tokens are written as HSL triples (`primary: '205 87% 53%'`) and the
+ * resolved Tailwind v4 `--color-*` vars as sRGB `rgb(...)` (`color-primary:
+ * 'rgb(31 153 239)'`) — the latter so `color-mix`-based alpha utilities resolve
+ * on native (see `getPresetVars` / `hslTripletToRgb`).
+ *
+ * Why a STATIC `import`, not a runtime `require` (critical)
+ * ---------------------------------------------------------
+ * react-native-css@3.0.7 ships both a `dist/commonjs` and a `dist/module` build, and
+ * Metro bundles BOTH. In `native-internal/root.js` the variable families are plain
+ * module-local consts — NOT `globalThis`-guarded the way `StyleCollection` is — so the
+ * commonjs `root.js` and the module `root.js` each instantiate their OWN separate
+ * `rootVariables` family. The react-native-css renderer (`react-native-css/src/components/View.tsx`
+ * → `varResolver`) imports its `root.js` via ESM `import`, i.e. the MODULE build. A
+ * runtime `require('react-native-css/native-internal')` resolves the package's `require`
+ * export condition → the COMMONJS build → a DIFFERENT family the renderer never
+ * subscribes to, so the writes are a silent no-op on device. A static top-level
+ * `import` resolves the `import` condition → the MODULE build → the renderer's instance.
+ *
+ * This plain file is the NATIVE/default variant (Metro selects it on iOS/Android,
+ * which have no `.native` override here); the web variant lives in the sibling
+ * `native-root-vars.web.ts` no-op, which web bundlers pick over this one. So the
+ * static `react-native-css/native-internal` import below is never pulled into a web
+ * bundle — only into native. This mirrors Bloom's existing platform-split convention
+ * (`color-scope/index.tsx` + `color-scope/index.web.tsx`, `FontLoader.native.tsx`).
+ *
+ * Keying contract (verified against react-native-css@3.0.7)
+ * ---------------------------------------------------------
+ * The `rootVariables` family is keyed by the BARE variable name, WITHOUT the leading
+ * `--`. The compiler strips it uniformly: a `:root { --primary: ... }` declaration is
+ * stored via `rule.v.push([property.slice(2), value])` then routed into
+ * `shared.rootVariables[name]`, and `@property --x` goes through
+ * `name.startsWith("--") ? name.slice(2) : name`. The lookup side matches: a `var(--x)`
+ * reference compiles to `[{}, "var", ident.slice(2)]`, so `varResolver` looks up the
+ * bare name. `buildScopeVars` returns keys WITH the `--` prefix, so we strip it before
+ * writing each entry.
+ *
+ * Value shape
+ * -----------
+ * Each entry is a `VariableValue[]` — an array of `[value, mediaCondition?]` tuples.
+ * Bloom's preset vars are unconditional, so each is a single-element `[[value]]`, e.g.
+ * `rootVariables('primary').set([['205 87% 53%']])`. This is the same shape the compiler
+ * emits for unconditional `:root` vars.
+ *
+ * This is native-only and additive: the `VariableContextProvider` wrapper stays (it is
+ * the correct, scoped mechanism for `BloomColorScope` subtree overrides and harmlessly
+ * covers direct descendants). The web fork (`native-root-vars.web.ts`) no-ops — web
+ * writes the same vars to `document.documentElement` via `applyColorPresetVars`.
+ */
+/**
+ * Write the preset's CSS vars to react-native-css's global `rootVariables` family
+ * so the whole native tree (navigator screens + portals/modals/bottom-sheets)
+ * resolves the active palette.
+ *
+ * Each `.set` notifies its own observers synchronously (react-native-css only
+ * batches notifications inside its own `StyleCollection.inject`; outside it,
+ * `observableBatch.current` is unset so every `.set` runs observers immediately),
+ * so sequential writes correctly trigger a re-render when the preset/mode changes.
+ *
+ * Defensive guard: if a host ships a react-native-css build that doesn't expose
+ * `rootVariables` as a callable (it always does on @3), we bail rather than throw.
+ */
+export declare function applyNativeRootVars(colorPreset: AppColorName, mode: 'light' | 'dark'): void;
+//# sourceMappingURL=native-root-vars.native.d.ts.map

package/lib/typescript/commonjs/theme/native-root-vars.native.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"native-root-vars.native.d.ts","sourceRoot":"","sources":["../../../../src/theme/native-root-vars.native.ts"],"names":[],"mappings":"AAmBA,OAAO,EAAE,KAAK,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAEpD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AAEH;;;;;;;;;;;;GAYG;AACH,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,YAAY,EAAE,IAAI,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAS3F"}

package/lib/typescript/module/theme/native-root-vars.d.ts

@@ -1,94 +1,34 @@
 import { type AppColorName } from './color-presets';
 /**
- * Publish the active color preset's CSS custom properties into react-native-css's
- * GLOBAL root-variable family so they reach the ENTIRE native app tree — including
- * content rendered outside the React subtree of `BloomThemeProvider`: expo-router
- * navigator screens, `Portal`s, `Dialog`/`BottomSheet` overlays, and any other host
- * that paints through a separate React root.
- *
- * Why a global write is required (native only)
- * --------------------------------------------
- * react-native-css resolves a `var(--x)` reference (its `varResolver`) in this order:
- *   1. `name in inheritedVariables`  — the React-context-inherited vars. This is what
- *      `VariableContextProvider` populates, but it is React-context-scoped, so it only
- *      reaches *direct descendants* of the provider in the React tree.
- *   2. `inlineVariables[name]`        — same-component inline vars.
- *   3. `variables[name]`             — resolved inherited vars.
- *   4. `universalVariables(name)`    — a GLOBAL observable family.
- *   5. `rootVariables(name)`         — a GLOBAL observable family.
- *   6. the declared fallback.
- *
- * `BloomThemeProvider`'s `VariableContextProvider` only feeds path #1, so the navigator
- * host and every portal/modal — which render outside that subtree — never see the
- * preset vars and fall through to `rootVariables`/`universalVariables`. By default those
- * families hold only react-native-css's own `__rn-css-rem`/`__rn-css-color` entries
- * (Bloom's `global.css` defines the `hsl(var(--primary))` indirection but not the HSL
- * triples themselves — those are injected at runtime), so the whole tree below the
- * navigator renders monochrome. Writing the vars into `rootVariables` here is the
- * exact same mechanism react-native-css uses for compiled `:root {}` / `@theme` vars
- * (`StyleCollection.inject` does `rootVariables(name).set(valueArray)`), so portaled
- * content resolves the palette identically regardless of React-tree position.
- *
- * The raw tokens are written as HSL triples (`primary: '205 87% 53%'`) and the
- * resolved Tailwind v4 `--color-*` vars as sRGB `rgb(...)` (`color-primary:
- * 'rgb(31 153 239)'`) — the latter so `color-mix`-based alpha utilities resolve
- * on native (see `getPresetVars` / `hslTripletToRgb`).
- *
- * Why a STATIC `import`, not a runtime `require` (critical)
- * ---------------------------------------------------------
- * react-native-css@3.0.7 ships both a `dist/commonjs` and a `dist/module` build, and
- * Metro bundles BOTH. In `native-internal/root.js` the variable families are plain
- * module-local consts — NOT `globalThis`-guarded the way `StyleCollection` is — so the
- * commonjs `root.js` and the module `root.js` each instantiate their OWN separate
- * `rootVariables` family. The react-native-css renderer (`react-native-css/src/components/View.tsx`
- * → `varResolver`) imports its `root.js` via ESM `import`, i.e. the MODULE build. A
- * runtime `require('react-native-css/native-internal')` resolves the package's `require`
- * export condition → the COMMONJS build → a DIFFERENT family the renderer never
- * subscribes to, so the writes are a silent no-op on device. A static top-level
- * `import` resolves the `import` condition → the MODULE build → the renderer's instance.
- *
- * This plain file is the NATIVE/default variant (Metro selects it on iOS/Android,
- * which have no `.native` override here); the web variant lives in the sibling
- * `native-root-vars.web.ts` no-op, which web bundlers pick over this one. So the
- * static `react-native-css/native-internal` import below is never pulled into a web
- * bundle — only into native. This mirrors Bloom's existing platform-split convention
- * (`color-scope/index.tsx` + `color-scope/index.web.tsx`, `FontLoader.native.tsx`).
- *
- * Keying contract (verified against react-native-css@3.0.7)
- * ---------------------------------------------------------
- * The `rootVariables` family is keyed by the BARE variable name, WITHOUT the leading
- * `--`. The compiler strips it uniformly: a `:root { --primary: ... }` declaration is
- * stored via `rule.v.push([property.slice(2), value])` then routed into
- * `shared.rootVariables[name]`, and `@property --x` goes through
- * `name.startsWith("--") ? name.slice(2) : name`. The lookup side matches: a `var(--x)`
- * reference compiles to `[{}, "var", ident.slice(2)]`, so `varResolver` looks up the
- * bare name. `buildScopeVars` returns keys WITH the `--` prefix, so we strip it before
- * writing each entry.
- *
- * Value shape
- * -----------
- * Each entry is a `VariableValue[]` — an array of `[value, mediaCondition?]` tuples.
- * Bloom's preset vars are unconditional, so each is a single-element `[[value]]`, e.g.
- * `rootVariables('primary').set([['205 87% 53%']])`. This is the same shape the compiler
- * emits for unconditional `:root` vars.
- *
- * This is native-only and additive: the `VariableContextProvider` wrapper stays (it is
- * the correct, scoped mechanism for `BloomColorScope` subtree overrides and harmlessly
- * covers direct descendants). The web fork (`native-root-vars.web.ts`) no-ops — web
- * writes the same vars to `document.documentElement` via `applyColorPresetVars`.
- */
-/**
- * Write the preset's CSS vars to react-native-css's global `rootVariables` family
- * so the whole native tree (navigator screens + portals/modals/bottom-sheets)
- * resolves the active palette.
- *
- * Each `.set` notifies its own observers synchronously (react-native-css only
- * batches notifications inside its own `StyleCollection.inject`; outside it,
- * `observableBatch.current` is unset so every `.set` runs observers immediately),
- * so sequential writes correctly trigger a re-render when the preset/mode changes.
- *
- * Defensive guard: if a host ships a react-native-css build that doesn't expose
- * `rootVariables` as a callable (it always does on @3), we bail rather than throw.
+ * Platform-neutral DEFAULT variant of `applyNativeRootVars` — a no-op.
+ *
+ * This is the file resolved by every bundler / type-checker that does NOT do
+ * React Native's platform-extension resolution:
+ *   - a consumer's `tsc` (resolving Bloom's `"react-native"` -> `./src/...` source
+ *     export condition: `theme/index.ts` -> `BloomThemeProvider` -> this import);
+ *   - non-Metro web bundlers (Vite/Rolldown, webpack) resolving the package
+ *     `exports` `import`/`require` conditions to `lib/.../native-root-vars.js`.
+ *
+ * It deliberately does NOT import `react-native-css/native-internal`. That subpath
+ * is native-only: it has no web build, and react-native-css is not even a Bloom
+ * dependency. Statically importing it from a file a web bundler resolves breaks
+ * module resolution outright (the original report: `Rolldown failed to resolve
+ * import "react-native-css/native-internal" from .../native-root-vars.js`).
+ * Importing it from a file a consumer's `tsc` resolves breaks type-check (TS2307).
+ *
+ * Confining the real implementation (and that import) to the `.native` sibling —
+ * `native-root-vars.native.ts`, which ONLY Metro selects — keeps both web bundling
+ * AND downstream `tsc` green, while native still publishes the preset vars into
+ * react-native-css's GLOBAL `rootVariables` family so the whole native tree
+ * (navigator screens + portals/modals) resolves the palette.
+ *
+ * The other variants:
+ *   - `native-root-vars.native.ts` — iOS/Android (Metro), the real implementation;
+ *   - `native-root-vars.web.ts` — web, also a no-op (web writes the same vars to
+ *     `document.documentElement` via `applyColorPresetVars` instead).
+ *
+ * The signature is intentionally identical to those variants so the import site in
+ * `BloomThemeProvider` is platform-agnostic.
  */
-export declare function applyNativeRootVars(colorPreset: AppColorName, mode: 'light' | 'dark'): void;
+export declare function applyNativeRootVars(_colorPreset: AppColorName, _mode: 'light' | 'dark'): void;
 //# sourceMappingURL=native-root-vars.d.ts.map

package/lib/typescript/module/theme/native-root-vars.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"native-root-vars.d.ts","sourceRoot":"","sources":["../../../../src/theme/native-root-vars.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,KAAK,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAEpD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AAEH;;;;;;;;;;;;GAYG;AACH,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,YAAY,EAAE,IAAI,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAS3F"}
+{"version":3,"file":"native-root-vars.d.ts","sourceRoot":"","sources":["../../../../src/theme/native-root-vars.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAEpD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAgB,mBAAmB,CAAC,YAAY,EAAE,YAAY,EAAE,KAAK,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAG7F"}

package/lib/typescript/module/theme/native-root-vars.native.d.ts

@@ -0,0 +1,94 @@
+import { type AppColorName } from './color-presets';
+/**
+ * Publish the active color preset's CSS custom properties into react-native-css's
+ * GLOBAL root-variable family so they reach the ENTIRE native app tree — including
+ * content rendered outside the React subtree of `BloomThemeProvider`: expo-router
+ * navigator screens, `Portal`s, `Dialog`/`BottomSheet` overlays, and any other host
+ * that paints through a separate React root.
+ *
+ * Why a global write is required (native only)
+ * --------------------------------------------
+ * react-native-css resolves a `var(--x)` reference (its `varResolver`) in this order:
+ *   1. `name in inheritedVariables`  — the React-context-inherited vars. This is what
+ *      `VariableContextProvider` populates, but it is React-context-scoped, so it only
+ *      reaches *direct descendants* of the provider in the React tree.
+ *   2. `inlineVariables[name]`        — same-component inline vars.
+ *   3. `variables[name]`             — resolved inherited vars.
+ *   4. `universalVariables(name)`    — a GLOBAL observable family.
+ *   5. `rootVariables(name)`         — a GLOBAL observable family.
+ *   6. the declared fallback.
+ *
+ * `BloomThemeProvider`'s `VariableContextProvider` only feeds path #1, so the navigator
+ * host and every portal/modal — which render outside that subtree — never see the
+ * preset vars and fall through to `rootVariables`/`universalVariables`. By default those
+ * families hold only react-native-css's own `__rn-css-rem`/`__rn-css-color` entries
+ * (Bloom's `global.css` defines the `hsl(var(--primary))` indirection but not the HSL
+ * triples themselves — those are injected at runtime), so the whole tree below the
+ * navigator renders monochrome. Writing the vars into `rootVariables` here is the
+ * exact same mechanism react-native-css uses for compiled `:root {}` / `@theme` vars
+ * (`StyleCollection.inject` does `rootVariables(name).set(valueArray)`), so portaled
+ * content resolves the palette identically regardless of React-tree position.
+ *
+ * The raw tokens are written as HSL triples (`primary: '205 87% 53%'`) and the
+ * resolved Tailwind v4 `--color-*` vars as sRGB `rgb(...)` (`color-primary:
+ * 'rgb(31 153 239)'`) — the latter so `color-mix`-based alpha utilities resolve
+ * on native (see `getPresetVars` / `hslTripletToRgb`).
+ *
+ * Why a STATIC `import`, not a runtime `require` (critical)
+ * ---------------------------------------------------------
+ * react-native-css@3.0.7 ships both a `dist/commonjs` and a `dist/module` build, and
+ * Metro bundles BOTH. In `native-internal/root.js` the variable families are plain
+ * module-local consts — NOT `globalThis`-guarded the way `StyleCollection` is — so the
+ * commonjs `root.js` and the module `root.js` each instantiate their OWN separate
+ * `rootVariables` family. The react-native-css renderer (`react-native-css/src/components/View.tsx`
+ * → `varResolver`) imports its `root.js` via ESM `import`, i.e. the MODULE build. A
+ * runtime `require('react-native-css/native-internal')` resolves the package's `require`
+ * export condition → the COMMONJS build → a DIFFERENT family the renderer never
+ * subscribes to, so the writes are a silent no-op on device. A static top-level
+ * `import` resolves the `import` condition → the MODULE build → the renderer's instance.
+ *
+ * This plain file is the NATIVE/default variant (Metro selects it on iOS/Android,
+ * which have no `.native` override here); the web variant lives in the sibling
+ * `native-root-vars.web.ts` no-op, which web bundlers pick over this one. So the
+ * static `react-native-css/native-internal` import below is never pulled into a web
+ * bundle — only into native. This mirrors Bloom's existing platform-split convention
+ * (`color-scope/index.tsx` + `color-scope/index.web.tsx`, `FontLoader.native.tsx`).
+ *
+ * Keying contract (verified against react-native-css@3.0.7)
+ * ---------------------------------------------------------
+ * The `rootVariables` family is keyed by the BARE variable name, WITHOUT the leading
+ * `--`. The compiler strips it uniformly: a `:root { --primary: ... }` declaration is
+ * stored via `rule.v.push([property.slice(2), value])` then routed into
+ * `shared.rootVariables[name]`, and `@property --x` goes through
+ * `name.startsWith("--") ? name.slice(2) : name`. The lookup side matches: a `var(--x)`
+ * reference compiles to `[{}, "var", ident.slice(2)]`, so `varResolver` looks up the
+ * bare name. `buildScopeVars` returns keys WITH the `--` prefix, so we strip it before
+ * writing each entry.
+ *
+ * Value shape
+ * -----------
+ * Each entry is a `VariableValue[]` — an array of `[value, mediaCondition?]` tuples.
+ * Bloom's preset vars are unconditional, so each is a single-element `[[value]]`, e.g.
+ * `rootVariables('primary').set([['205 87% 53%']])`. This is the same shape the compiler
+ * emits for unconditional `:root` vars.
+ *
+ * This is native-only and additive: the `VariableContextProvider` wrapper stays (it is
+ * the correct, scoped mechanism for `BloomColorScope` subtree overrides and harmlessly
+ * covers direct descendants). The web fork (`native-root-vars.web.ts`) no-ops — web
+ * writes the same vars to `document.documentElement` via `applyColorPresetVars`.
+ */
+/**
+ * Write the preset's CSS vars to react-native-css's global `rootVariables` family
+ * so the whole native tree (navigator screens + portals/modals/bottom-sheets)
+ * resolves the active palette.
+ *
+ * Each `.set` notifies its own observers synchronously (react-native-css only
+ * batches notifications inside its own `StyleCollection.inject`; outside it,
+ * `observableBatch.current` is unset so every `.set` runs observers immediately),
+ * so sequential writes correctly trigger a re-render when the preset/mode changes.
+ *
+ * Defensive guard: if a host ships a react-native-css build that doesn't expose
+ * `rootVariables` as a callable (it always does on @3), we bail rather than throw.
+ */
+export declare function applyNativeRootVars(colorPreset: AppColorName, mode: 'light' | 'dark'): void;
+//# sourceMappingURL=native-root-vars.native.d.ts.map

package/lib/typescript/module/theme/native-root-vars.native.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"native-root-vars.native.d.ts","sourceRoot":"","sources":["../../../../src/theme/native-root-vars.native.ts"],"names":[],"mappings":"AAmBA,OAAO,EAAE,KAAK,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAEpD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AAEH;;;;;;;;;;;;GAYG;AACH,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,YAAY,EAAE,IAAI,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAS3F"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oxyhq/bloom",
-  "version": "0.7.4",
+  "version": "0.7.6",
   "description": "Bloom UI — Oxy ecosystem component library for React Native + Expo + Web",
   "main": "lib/commonjs/index.js",
   "module": "lib/module/index.js",

package/src/__tests__/native-root-vars.test.ts

@@ -1,10 +1,11 @@
 type SetCall = ReadonlyArray<readonly [string]>;
 
 /**
- * Verifies the native/default variant `theme/native-root-vars.ts` publishes the
+ * Verifies the native variant `theme/native-root-vars.native.ts` publishes the
  * active preset into react-native-css's GLOBAL `rootVariables` family with the
  * exact keying and value shape react-native-css itself uses for compiled `:root`
- * vars, and that the web fork `theme/native-root-vars.web.ts` is an inert no-op.
+ * vars, and that BOTH the platform-neutral default (`theme/native-root-vars.ts`)
+ * and the web fork (`theme/native-root-vars.web.ts`) are inert no-ops.
  *
  *  - keys are written WITHOUT the leading `--` (the family is keyed by the bare
  *    name — confirmed against react-native-css@3.0.7's compiler, which stores
@@ -12,6 +13,11 @@ type SetCall = ReadonlyArray<readonly [string]>;
  *  - each value is a single-element value-array `[[value]]` (`VariableValue[]`);
  *  - the native variant reaches react-native-css via a STATIC ESM import (so
  *    Metro resolves the `module` build — the SAME family the renderer reads);
+ *  - the default variant never imports react-native-css and writes nothing — it
+ *    is what `tsc` and non-Metro web bundlers (Vite/Rolldown) resolve, so
+ *    confining the `react-native-css/native-internal` import to the `.native`
+ *    variant keeps web bundling resolvable AND a NativeWind-4 consumer's `tsc`
+ *    from failing with TS2307;
  *  - the web variant never imports react-native-css and writes nothing.
  *
  * react-native-css is NOT a Bloom dependency (it arrives transitively via the
@@ -40,7 +46,7 @@ describe('applyNativeRootVars (native variant)', () => {
         { virtual: true },
       );
 
-      const { applyNativeRootVars } = require('../theme/native-root-vars') as {
+      const { applyNativeRootVars } = require('../theme/native-root-vars.native') as {
         applyNativeRootVars: (preset: string, mode: 'light' | 'dark') => void;
       };
       applyNativeRootVars('blue', 'light');
@@ -81,7 +87,7 @@ describe('applyNativeRootVars (native variant)', () => {
           }),
           { virtual: true },
         );
-        const { applyNativeRootVars } = require('../theme/native-root-vars') as {
+        const { applyNativeRootVars } = require('../theme/native-root-vars.native') as {
           applyNativeRootVars: (preset: string, mode: 'light' | 'dark') => void;
         };
         applyNativeRootVars('teal', mode);
@@ -99,10 +105,30 @@ describe('applyNativeRootVars (native variant)', () => {
         () => ({ rootVariables: undefined }),
         { virtual: true },
       );
+      const { applyNativeRootVars } = require('../theme/native-root-vars.native') as {
+        applyNativeRootVars: (preset: string, mode: 'light' | 'dark') => void;
+      };
+      expect(() => applyNativeRootVars('blue', 'light')).not.toThrow();
+    });
+  });
+});
+
+describe('applyNativeRootVars (default variant - tsc / web-bundler resolution)', () => {
+  beforeEach(() => {
+    jest.resetModules();
+  });
+
+  it('no-ops without importing react-native-css (keeps web bundling + tsc green)', () => {
+    // The platform-neutral default is what a consumer's `tsc` and non-Metro web
+    // bundlers (Vite/Rolldown) resolve. It must never touch react-native-css.
+    // Confining the `react-native-css/native-internal` import to the `.native`
+    // sibling fixes both the downstream TS2307 AND the Vite/Rolldown resolve fail.
+    jest.isolateModules(() => {
       const { applyNativeRootVars } = require('../theme/native-root-vars') as {
         applyNativeRootVars: (preset: string, mode: 'light' | 'dark') => void;
       };
       expect(() => applyNativeRootVars('blue', 'light')).not.toThrow();
+      expect(applyNativeRootVars('blue', 'light')).toBeUndefined();
     });
   });
 });