@symbiote-native/engine 1.2.0 → 1.3.1

package/build/platform/index.android.js

@@ -3,7 +3,7 @@
 // from the PlatformConstants native module (RN spec NativePlatformConstantsAndroid.js,
 // a different payload from iOS). Metro picks this on an Android host. The module name is
 // the same 'PlatformConstants'; only the shape differs.
-import { createConstantsResolver, } from './shared.js';
+import { createConstantsResolver, gatedIsTesting, } from './shared.js';
 // The filename already selected this host: 'android' is a literal, not a probe.
 const OS_ANDROID = 'android';
 // RN reads isTV off the uiMode constant.
@@ -37,14 +37,12 @@ export const Platform = {
     get isVision() {
         return false;
     },
-    // RN gates this behind __DEV__; shared has no __DEV__ flag, so we read the native
-    // flag directly: a release build's native module reports false anyway.
     get isTesting() {
-        return resolveConstants()?.isTesting ?? false;
+        return gatedIsTesting(resolveConstants());
     },
     get isDisableAnimations() {
         const constants = resolveConstants();
-        return constants?.isDisableAnimations ?? constants?.isTesting ?? false;
+        return constants?.isDisableAnimations ?? gatedIsTesting(constants);
     },
     get isMacCatalyst() {
         return false;

package/build/platform/index.ios.js

@@ -3,7 +3,7 @@
 // (RN spec NativePlatformConstantsIOS.js), read lazily and cached via the shared
 // resolver. Metro picks this on an iOS host; it is also the base re-export target
 // (platform.ts) so tsc / tsx / web (no Metro) land here too.
-import { createConstantsResolver, UNKNOWN_VERSION, } from './shared.js';
+import { createConstantsResolver, gatedIsTesting, UNKNOWN_VERSION, } from './shared.js';
 // interfaceIdiom values RN compares against for the device-class getters.
 const IDIOM_PAD = 'pad';
 const IDIOM_TV = 'tv';
@@ -39,13 +39,13 @@ export const Platform = {
         return idiomEquals(IDIOM_VISION);
     },
     get isTesting() {
-        return resolveConstants()?.isTesting ?? false;
+        return gatedIsTesting(resolveConstants());
     },
     // RN: isDisableAnimations ?? isTesting. The native flag wins; absent, it tracks
     // isTesting (test runs disable animations by default).
     get isDisableAnimations() {
         const constants = resolveConstants();
-        return constants?.isDisableAnimations ?? constants?.isTesting ?? false;
+        return constants?.isDisableAnimations ?? gatedIsTesting(constants);
     },
     get isMacCatalyst() {
         return resolveConstants()?.isMacCatalyst ?? false;

package/build/platform/shared.d.ts

@@ -23,3 +23,7 @@ export interface IPlatformStatic<TConstants> {
     select<T>(spec: IPlatformSelectSpec<T>): T | undefined;
 }
 export declare function createConstantsResolver<TConstants>(guard: (value: unknown) => value is TConstants): () => TConstants | undefined;
+export declare function isDevBuild(): boolean;
+export declare function gatedIsTesting(constants: {
+    isTesting?: boolean;
+} | undefined): boolean;

package/build/platform/shared.js

@@ -38,3 +38,12 @@ export function createConstantsResolver(guard) {
         return cached;
     };
 }
+// Metro's `__DEV__` global: `true` in a dev bundle, `false` in release. Read off globalThis so a
+// host that never defines it (headless tooling) counts as release, like any unset flag.
+export function isDevBuild() {
+    return Reflect.get(globalThis, '__DEV__') === true;
+}
+// RN's `isTesting`: the native flag in a dev build only (`if (__DEV__) … return false`).
+export function gatedIsTesting(constants) {
+    return isDevBuild() && (constants?.isTesting ?? false);
+}

package/build/platform-color/index.android.d.ts

@@ -0,0 +1,4 @@
+import type { IDynamicColorIOSTuple, IOpaqueColorValue } from './shared';
+export * from './shared';
+export declare function PlatformColor(...names: string[]): IOpaqueColorValue;
+export declare function DynamicColorIOS(_tuple: IDynamicColorIOSTuple): IOpaqueColorValue;

package/build/platform-color/index.android.js

@@ -0,0 +1,7 @@
+export * from './shared.js';
+export function PlatformColor(...names) {
+    return { resource_paths: names };
+}
+export function DynamicColorIOS(_tuple) {
+    throw new Error('DynamicColorIOS is not available on this platform.');
+}

package/build/platform-color/index.d.ts

@@ -1,22 +1,4 @@
-export interface IDynamicColorIOSTuple {
-    light: IColorValue;
-    dark: IColorValue;
-    highContrastLight?: IColorValue;
-    highContrastDark?: IColorValue;
-}
-export interface IOpaqueColorValue {
-    readonly semantic?: readonly string[];
-    readonly dynamic?: {
-        readonly light: IColorValue;
-        readonly dark: IColorValue;
-        readonly highContrastLight?: IColorValue;
-        readonly highContrastDark?: IColorValue;
-    };
-}
-export type IColorValue = string | number | IOpaqueColorValue;
+import type { IDynamicColorIOSTuple, IOpaqueColorValue } from './shared';
+export * from './shared';
 export declare function PlatformColor(...names: string[]): IOpaqueColorValue;
 export declare function DynamicColorIOS(tuple: IDynamicColorIOSTuple): IOpaqueColorValue;
-export declare function isOpaqueColorValue(value: unknown): value is IOpaqueColorValue;
-export declare function setColorProcessor(process: (value: IColorValue) => unknown): void;
-export declare function processColor(color: IColorValue): unknown;
-export declare function isProcessableColor(value: unknown): value is IColorValue;

package/build/platform-color/index.js

@@ -1,10 +1,4 @@
-// PlatformColor / DynamicColorIOS: opaque color values the native side resolves
-// (iOS UIColor: semantic system colors and appearance-aware light/dark tuples).
-// These are pure object constructors with no native dependency, so they live in
-// shared and every adapter re-exports them. The opaque shape ({ semantic } /
-// { dynamic }) is exactly what RN's processColor and the iOS RCTConvert UIColor
-// path read, so our commit-time color seam routes these objects through the
-// injected processor just like CSS-string colors (see commit.ts processValue).
+export * from './shared.js';
 export function PlatformColor(...names) {
     return { semantic: names };
 }
@@ -18,41 +12,3 @@ export function DynamicColorIOS(tuple) {
         },
     };
 }
-// True for the opaque objects above: the color seam uses this to route them
-// through the platform processor alongside CSS-string colors.
-export function isOpaqueColorValue(value) {
-    return (typeof value === 'object' &&
-        value !== null &&
-        ('semantic' in value || 'dynamic' in value));
-}
-// Color props must reach Fabric as platform ints, not CSS strings. Fabric's C++ color
-// parser silently drops strings. The actual conversion (processColor) is RN-platform-specific,
-// so it is injected here rather than imported, keeping shared free of a react-native dependency
-// (and the headless harness working). This module is the sole owner of "run a value through the
-// platform color processor" - every color-touching consumer (commit's fabricProps,
-// process-box-shadow, process-filter, process-background-image, StatusBar android) imports
-// processColor/isProcessableColor from here, never from commit.ts.
-let colorProcessor = value => value;
-export function setColorProcessor(process) {
-    colorProcessor = process;
-}
-// Public mirror of RN's processColor: run a color through the injected platform processor (the
-// canary wires RN's own). Off a real host it resolves CSS strings and opaque PlatformColor
-// objects to the platform ints Fabric expects; headless (no processor wired) it is the identity,
-// so smokes see the input unchanged.
-export function processColor(color) {
-    return colorProcessor(color);
-}
-// A color-keyed value the platform processor must convert before Fabric: a CSS string, a numeric
-// literal, or an opaque PlatformColor / DynamicColorIOS object. `undefined` is left untouched.
-//
-// A number used to be excluded here on the reasoning that it was "already a resolved platform
-// int". Nothing in the pipeline produces one: the CSS parser emits hex STRINGS, and fabricProps
-// builds a fresh payload object instead of writing the resolved value back into node.props, so a
-// number reaching this guard is always the author's own literal. Excluding it committed
-// `color: 0xff0000ff` (opaque red, rrggbbaa) unrotated, and native reads that as aarrggbb: blue.
-export function isProcessableColor(value) {
-    return (typeof value === 'string' ||
-        typeof value === 'number' ||
-        isOpaqueColorValue(value));
-}

package/build/platform-color/shared.d.ts

@@ -0,0 +1,21 @@
+export interface IDynamicColorIOSTuple {
+    light: IColorValue;
+    dark: IColorValue;
+    highContrastLight?: IColorValue;
+    highContrastDark?: IColorValue;
+}
+export interface IOpaqueColorValue {
+    readonly semantic?: readonly string[];
+    readonly resource_paths?: readonly string[];
+    readonly dynamic?: {
+        readonly light: IColorValue;
+        readonly dark: IColorValue;
+        readonly highContrastLight?: IColorValue;
+        readonly highContrastDark?: IColorValue;
+    };
+}
+export type IColorValue = string | number | IOpaqueColorValue;
+export declare function isOpaqueColorValue(value: unknown): value is IOpaqueColorValue;
+export declare function setColorProcessor(process: (value: IColorValue) => unknown): void;
+export declare function processColor(color: IColorValue): unknown;
+export declare function isProcessableColor(value: unknown): value is IColorValue;

package/build/platform-color/shared.js

@@ -0,0 +1,41 @@
+// PlatformColor / DynamicColorIOS: opaque colors native resolves. Constructors are per platform
+// because the shapes differ: iOS reads { semantic } / { dynamic } (PlatformColorParser.mm),
+// Android only { resource_paths } (ColorPropConverter). The C++ seam forwards the object as-is.
+// True for the opaque objects above: the color seam uses this to route them
+// through the platform processor alongside CSS-string colors.
+export function isOpaqueColorValue(value) {
+    return (typeof value === 'object' &&
+        value !== null &&
+        ('semantic' in value || 'dynamic' in value || 'resource_paths' in value));
+}
+// Color props must reach Fabric as platform ints, not CSS strings. Fabric's C++ color
+// parser silently drops strings. The actual conversion (processColor) is RN-platform-specific,
+// so it is injected here rather than imported, keeping shared free of a react-native dependency
+// (and the headless harness working). This module is the sole owner of "run a value through the
+// platform color processor" - every color-touching consumer (commit's fabricProps,
+// process-box-shadow, process-filter, process-background-image, StatusBar android) imports
+// processColor/isProcessableColor from here, never from commit.ts.
+let colorProcessor = value => value;
+export function setColorProcessor(process) {
+    colorProcessor = process;
+}
+// Public mirror of RN's processColor: run a color through the injected platform processor (the
+// canary wires RN's own). Off a real host it resolves CSS strings and opaque PlatformColor
+// objects to the platform ints Fabric expects; headless (no processor wired) it is the identity,
+// so smokes see the input unchanged.
+export function processColor(color) {
+    return colorProcessor(color);
+}
+// A color-keyed value the platform processor must convert before Fabric: a CSS string, a numeric
+// literal, or an opaque PlatformColor / DynamicColorIOS object. `undefined` is left untouched.
+//
+// A number used to be excluded here on the reasoning that it was "already a resolved platform
+// int". Nothing in the pipeline produces one: the CSS parser emits hex STRINGS, and fabricProps
+// builds a fresh payload object instead of writing the resolved value back into node.props, so a
+// number reaching this guard is always the author's own literal. Excluding it committed
+// `color: 0xff0000ff` (opaque red, rrggbbaa) unrotated, and native reads that as aarrggbb: blue.
+export function isProcessableColor(value) {
+    return (typeof value === 'string' ||
+        typeof value === 'number' ||
+        isOpaqueColorValue(value));
+}

package/build/post-commit.js

@@ -1,11 +1,6 @@
-// Post-commit hooks: run once after every native commit that changed the tree (after
-// completeRoot, when fresh Fabric tags have just been assigned). The seam exists so a
-// consumer that needs a node's committed tag — today only the Animated native driver,
-// which binds a props node to a view tag — can retry work that ran too early under an
-// async-batched commit (Vue/Svelte schedule completeRoot on a microtask, so lifecycle
-// code can reach a node before its tag exists; React commits synchronously and never
-// queues). A neutral module so commit.ts and animated/props.ts share it without a
-// dependency cycle.
+// Run once after every commit that changed the tree, once fresh Fabric tags exist — lets a
+// consumer needing a node's committed tag (the Animated native driver) retry work that ran too
+// early under an async-batched commit. Shared by commit.ts and animated/props.ts, cycle-free.
 const hooks = new Set();
 export function registerPostCommit(hook) {
     hooks.add(hook);

package/build/process-aspect-ratio.js

@@ -1,10 +1,6 @@
-// JS-side port of RN's processAspectRatio (Libraries/StyleSheet/processAspectRatio.js).
-// Same root cause family as boxShadow/filter: RN registers `aspectRatio` with a JS
-// `process` because enableNativeCSSParsing() defaults to false, so the CSS ratio string
-// ('16 / 9') is resolved to a number IN JS before native. A plain number (the common,
-// already-working form) passes through untouched; this is a no-op for it.
-//
-// RN throws via invariant() in __DEV__ on a malformed value; we dlog and return undefined.
+// JS-side port of RN's processAspectRatio: resolves a CSS ratio string ('16 / 9') to a number
+// before native, same root cause as boxShadow/filter. A plain number passes through untouched.
+// RN throws via invariant() on a malformed value; here we dlog and return undefined instead.
 import { dlog } from './debug.js';
 // RN processAspectRatio.js:15-63. number → number; ratio string → number; invalid → undefined.
 export function processAspectRatio(aspectRatio) {

package/build/process-background-longhands.js

@@ -1,20 +1,12 @@
 // RN's own processBackgroundSize / processBackgroundPosition / processBackgroundRepeat, imported
 // rather than ported.
-//
-// Why they are needed at all: ReactNativeStyleAttributes registers all three with
-// `nativeCSSParsing ? true : {process: processX}` (:50, :54, :58), and enableNativeCSSParsing()
-// defaults to false - so RN's stock path parses the CSS string into the per-axis structure
-// Fabric's C++ expects. We registered `experimental_backgroundImage` and not its three siblings,
-// so a string for any of them reached native unparsed: dropped on iOS, cast to the wrong
-// ReadableMap type on Android. Same shape as the process-transform incident.
-//
-// Why importing is free here even by this repo's strictest reading: all three upstream files
-// contain ONLY `import type` lines. Their value-import closure is empty - no processColor, no
-// Platform, no TurboModule floor, no renderer. There is nothing to weigh.
-//
-// Why no try/catch, unlike the other upstream wrappers: these three do not validate through
-// `invariant`. They answer `[]` for anything they cannot parse, which upstream's own comment calls
-// "do not apply any background" - so refusal is a RETURN here, not a throw.
+// Needed because enableNativeCSSParsing() defaults to false, so RN's stock JS path parses the CSS
+// string into the per-axis structure Fabric's C++ expects. Without it a string for any of these
+// three reached native unparsed: dropped on iOS, cast to the wrong ReadableMap type on Android.
+// Importing is free here: all three upstream files contain only `import type` lines, so their
+// value-import closure is empty — no processColor, no Platform, no TurboModule floor, no renderer.
+// No try/catch, unlike the other upstream wrappers: these three don't validate through invariant,
+// they answer `[]` for anything unparseable — so refusal is a return here, not a throw.
 import { dlog } from './debug.js';
 // @ts-expect-error - untyped Flow source. Metro compiles it; vitest.config.ts strips the types.
 import processBackgroundSizeUpstream from 'react-native/Libraries/StyleSheet/processBackgroundSize';
@@ -22,10 +14,9 @@ import processBackgroundSizeUpstream from 'react-native/Libraries/StyleSheet/pro
 import processBackgroundPositionUpstream from 'react-native/Libraries/StyleSheet/processBackgroundPosition';
 // @ts-expect-error - untyped Flow source. Metro compiles it; vitest.config.ts strips the types.
 import processBackgroundRepeatUpstream from 'react-native/Libraries/StyleSheet/processBackgroundRepeat';
-// An empty result is upstream's way of saying it parsed nothing usable. The payload builder's
-// rule is that a refused processor leaves the key ABSENT, so it must not become `[]` - an empty
-// array is a real value, and committing one asks native to apply "no background size" rather than
-// leaving the declaration unset.
+// An empty result means upstream parsed nothing usable. The payload builder's rule is that a
+// refused processor leaves the key absent — `[]` is a real value, committing it would ask native
+// to apply "no background size" rather than leave the declaration unset.
 function orAbsent(parsed, key, value) {
     if (!Array.isArray(parsed) || parsed.length === 0) {
         dlog(`${key}: RN parsed nothing usable from ${JSON.stringify(value)}`);

package/build/process-filter.js

@@ -1,22 +1,14 @@
-// RN's own processFilter, imported rather than ported.
-//
-// Why it is needed at all: RN registers `filter` with `nativeCSSParsing ? true : {process:
-// processFilter}`, and enableNativeCSSParsing() defaults to false - so the stock path parses the
-// CSS string / structured array in JS and native never sees the raw string.
-//
-// Why the try/catch, unlike processBoxShadow's wrapper: upstream throws exactly once
-// (processFilter.js:120, a TypeError for an input that is neither string nor array), and a commit
-// path must never throw. fabric-props narrows before calling, but `processFilter` is on the public
-// barrel, so the guard is reachable rather than ceremonial.
-//
-// What changed by importing: a drop-shadow's colour now goes through RN's own `processColor`
-// (upstream imports it directly at processFilter.js:16) instead of our injected
-// `setColorProcessor` seam. On a real host those are the same function - bootstrapHost injects
-// exactly `processColor` - so the seam simply no longer governs the colour inside a filter.
-//
-// Platform caveat worth keeping in view when demoing this: on iOS RN paints only `brightness` and
-// `opacity` unless enableSwiftUIBasedFilters is on, so grayscale/blur/saturate/contrast/hueRotate
-// parse correctly here and still do nothing on screen.
+// RN's own processFilter, imported rather than ported: enableNativeCSSParsing() defaults to
+// false, so the stock path parses the CSS string / structured array in JS and native never sees
+// the raw string.
+// try/catch because upstream throws once (a TypeError for a non-string/array input) and a commit
+// path must never throw; fabric-props narrows first, but processFilter is on the public barrel
+// too, so the guard here stays reachable, not ceremonial.
+// A drop-shadow's color goes through RN's own processColor here, not our injected
+// setColorProcessor seam — the same function on a real host, since bootstrapHost injects exactly
+// processColor, so the seam simply doesn't govern a filter's color.
+// iOS caveat: RN paints only brightness/opacity unless enableSwiftUIBasedFilters is on, so
+// grayscale/blur/saturate/contrast/hueRotate parse fine here and still paint nothing on screen.
 import { dlog } from './debug.js';
 // @ts-expect-error - untyped Flow source. Metro compiles it; vitest.config.ts strips the types.
 import processFilterUpstream from 'react-native/Libraries/StyleSheet/processFilter';

package/build/process-font-variant.js

@@ -1,10 +1,6 @@
-// JS-side port of RN's processFontVariant (Libraries/StyleSheet/processFontVariant.js).
-// Same root cause family as boxShadow/filter: RN registers `fontVariant` with a JS
-// `process` because enableNativeCSSParsing() defaults to false, so a space-separated CSS
-// string ('small-caps tabular-nums') is split into the array native expects IN JS. An
-// array (the common, already-working form) passes through untouched; this is a no-op
-// for it.
-// RN processFontVariant.js:15-28. Array → array; space-separated string → array of variants.
+// JS-side port of RN's processFontVariant: splits a space-separated CSS string
+// ('small-caps tabular-nums') into the array native expects, same root cause as
+// boxShadow/filter. An array (the common, already-working form) passes through as a no-op.
 export function processFontVariant(fontVariant) {
     if (Array.isArray(fontVariant)) {
         return fontVariant;

package/build/registry.d.ts

@@ -29,39 +29,6 @@ export declare function registerComponent(name: string, registration?: IComponen
 export declare function isRegisteredEvent(component: string, listener: string): boolean;
 export declare function registeredNativeEvent(component: string, raw: string): INativeEventBinding | undefined;
 export declare function registeredProcessor(component: string, key: string): IPropProcessor | undefined;
-/**
- * A component's ViewConfig processors, as a payload fold — or undefined when it has none.
- *
- * WHY A FOLD AND NOT A LOOKUP AT PAYLOAD-BUILD TIME. The payload is built in C++ on a device
- * (`core/engine/cpp/SymbioteFabricProps.cpp`) and only in JS headless, and this registry cannot
- * cross that boundary: it is populated lazily from an INJECTED `ReactNativeViewConfigRegistry`
- * lookup, holding JS closures. `payloadFold` is the one seam that already runs in JS on both paths
- * — the C++ probes it once per node and calls back — so putting the processors there is what makes
- * a third-party view behave the same on a device as it does in a test.
- *
- * The alternative was a list of prop NAMES in C++, and that is what this replaces. It cost a day:
- * `@symbiote-native/slider` declares `minimumTrackTintColor` / `maximumTrackTintColor` in its own
- * ViewConfig, neither name was in the C++ list, both reached Fabric as CSS strings, and iOS answers
- * a string colour with `clearColor()`. The slider dragged and reported values correctly with no
- * track drawn at all. Any list of names is a list somebody has to extend for a component we have
- * never seen — which would have meant editing C++ to add a native view, and that is exactly the
- * coupling `<native_core_is_untouched>` exists to prevent.
- *
- * Resolved ONCE per component and cached, because `createElement` asks per node. A built-in
- * short-circuits inside `resolve` before any of this.
- */
-/**
- * The prop names a component's OWN ViewConfig claims a processor for — i.e. exactly the keys
- * `configPayloadFold` has already converted by the time the payload builder's own passes run.
- *
- * It exists so "a colour is converted exactly once" can be a stated rule rather than a lucky one.
- * The overlap is real: `thumbTintColor` is claimed by @symbiote-native/slider's config AND by the
- * engine's built-in COLOR_PROPS, and for a while nothing broke only because a processed colour came
- * back as a NUMBER and the engine skipped numbers. That guard died when a numeric colour became
- * processable in its own right — an author writing `color: 0xff0000ff` means rrggbbaa and owes the
- * same rotation a string owes — and the second conversion then turned an already-correct int into
- * a different colour.
- */
 export declare function configProcessedKeys(component: string): ReadonlySet<string> | undefined;
 export declare function configPayloadFold(component: string): IPayloadFold | undefined;
 export {};

package/build/registry.js

@@ -1,33 +1,19 @@
-// Runtime metadata for native Fabric views, DERIVED BY DEFAULT. Any RN library
-// already ships its own ViewConfig: codegen registers it into RN's
-// ReactNativeViewConfigRegistry the moment the library's native-component module is
-// imported. That config carries everything the shared engine can't infer: which
-// events the view emits (bubblingEventTypes / directEventTypes) and how to process
-// its props (validAttributes[*].process, e.g. processColor). So we DON'T transcribe
-// any of it, and we don't mark anything "third-party": there is no
-// per-package registration to maintain. The engine reads the config for ANY
-// component on first use. Install a community view library, render it, done.
-//
-// shared must stay react-native-free (the headless harness runs in plain Node), so
-// the ViewConfig lookup is INJECTED, exactly like the color processor: the adapter
-// wires `setNativeViewConfigSource(ReactNativeViewConfigRegistry.get)` on a real
-// host, where that one source covers BOTH RN core and every library.
-//
-// The ONLY explicit list is OUR OWN built-in primitives (BUILTIN_COMPONENTS): a
-// finite set we own, which keep their hand-tuned tables (view-config events, commit
-// COLOR_PROPS) and are never read from the source, so they can't drift. Everything
-// NOT in that set derives. The list never grows with the community; it grows only
-// when we add a core primitive of our own.
+// Runtime metadata for native Fabric views, derived by default. Any RN library ships its own
+// ViewConfig via codegen, carrying everything the shared engine can't infer — which events a view
+// emits, how to process its props. Nothing is transcribed; read from the config on first use.
+// shared must stay react-native-free (the headless harness runs in plain Node), so the ViewConfig
+// lookup is injected, exactly like the color processor: the adapter wires
+// setNativeViewConfigSource(ReactNativeViewConfigRegistry.get) on a real host.
+// The only explicit list is our own built-in primitives (BUILTIN_COMPONENTS): a finite set we own,
+// which keep their hand-tuned tables and are never read from the source, so they can't drift. It
+// grows only when we add a core primitive of our own, never for a community package.
 import { isRecord } from './type-guards.js';
 const EMPTY = {
     listeners: new Set(),
     byRaw: new Map(),
     processors: new Map(),
 };
-// OUR own primitives: the finite set shared hand-tunes (view-config events,
-// commit COLOR_PROPS). The source is never consulted for these, so they can't
-// drift. Everything else derives. This list grows only when WE add a core
-// primitive, never for a community package.
+// Our own primitives — see the module header for why the source is never consulted for these.
 const BUILTIN_COMPONENTS = new Set([
     'RCTView',
     'RCTText',
@@ -156,39 +142,18 @@ export function registeredNativeEvent(component, raw) {
 export function registeredProcessor(component, key) {
     return resolve(component).processors.get(key);
 }
-/**
- * A component's ViewConfig processors, as a payload fold — or undefined when it has none.
- *
- * WHY A FOLD AND NOT A LOOKUP AT PAYLOAD-BUILD TIME. The payload is built in C++ on a device
- * (`core/engine/cpp/SymbioteFabricProps.cpp`) and only in JS headless, and this registry cannot
- * cross that boundary: it is populated lazily from an INJECTED `ReactNativeViewConfigRegistry`
- * lookup, holding JS closures. `payloadFold` is the one seam that already runs in JS on both paths
- * — the C++ probes it once per node and calls back — so putting the processors there is what makes
- * a third-party view behave the same on a device as it does in a test.
- *
- * The alternative was a list of prop NAMES in C++, and that is what this replaces. It cost a day:
- * `@symbiote-native/slider` declares `minimumTrackTintColor` / `maximumTrackTintColor` in its own
- * ViewConfig, neither name was in the C++ list, both reached Fabric as CSS strings, and iOS answers
- * a string colour with `clearColor()`. The slider dragged and reported values correctly with no
- * track drawn at all. Any list of names is a list somebody has to extend for a component we have
- * never seen — which would have meant editing C++ to add a native view, and that is exactly the
- * coupling `<native_core_is_untouched>` exists to prevent.
- *
- * Resolved ONCE per component and cached, because `createElement` asks per node. A built-in
- * short-circuits inside `resolve` before any of this.
- */
-/**
- * The prop names a component's OWN ViewConfig claims a processor for — i.e. exactly the keys
- * `configPayloadFold` has already converted by the time the payload builder's own passes run.
- *
- * It exists so "a colour is converted exactly once" can be a stated rule rather than a lucky one.
- * The overlap is real: `thumbTintColor` is claimed by @symbiote-native/slider's config AND by the
- * engine's built-in COLOR_PROPS, and for a while nothing broke only because a processed colour came
- * back as a NUMBER and the engine skipped numbers. That guard died when a numeric colour became
- * processable in its own right — an author writing `color: 0xff0000ff` means rrggbbaa and owes the
- * same rotation a string owes — and the second conversion then turned an already-correct int into
- * a different colour.
- */
+// A component's ViewConfig processors, as a payload fold — or undefined when it has none. Not a
+// lookup at payload-build time: the payload is built in C++ on a device and this registry can't
+// cross that boundary (it's populated lazily from an injected JS-closure-holding lookup).
+// payloadFold is the one seam that already runs in JS on both paths, so putting the processors
+// there is what makes a third-party view behave the same on device as in a test. The alternative,
+// a list of prop names hardcoded in C++, needs editing native code for every new component we see.
+// Resolved once per component and cached, since createElement asks per node. A built-in
+// short-circuits inside resolve before any of this.
+// The prop names a component's own ViewConfig claims a processor for — exactly the keys
+// configPayloadFold has already converted by the time the payload builder's own passes run.
+// Exists so "a colour is converted exactly once" is a stated rule, not a lucky one: an overlap
+// between a third-party config and the engine's own COLOR_PROPS would otherwise double-convert.
 export function configProcessedKeys(component) {
     const cached = keysCache.get(component);
     if (cached !== undefined)

package/build/report-error.js

@@ -1,21 +1,8 @@
 // Hand an error to the host the way React Native itself does, for the seams where an adapter
 // catches something its framework would otherwise have surfaced on its own.
-//
-// RN routes an uncaught render error through ReactFiberErrorDialog -> ExceptionsManager
-// (Libraries/Core/ReactFiberErrorDialog.js), which is reachable only by a deep path into RN's
-// Libraries. `global.ErrorUtils` is the same surface through the documented global that
-// @react-native/js-polyfills installs before any module evaluates - RN's own
-// Libraries/vendor/core/ErrorUtils.js is nothing but `export default global.ErrorUtils`. Off a
-// native host (vitest, node smokes) the global is absent and console.error is the whole channel.
-//
-// This is NOT the dlog channel. dlog is DEBUG-gated and therefore the developer's; an error that
-// blanked the screen has to reach the app whether or not anyone turned diagnostics on.
-// Read off globalThis through Reflect rather than named as an identifier, and deliberately NOT
-// declared in an ambient block: react-native ships its own `const ErrorUtils: ErrorUtils` in
-// src/types/globals.d.ts, so a `declare global { var ErrorUtils }` here redeclares it (TS2451) for
-// every package whose tsconfig pulls in RN's types - the engine's own does not, so it typechecks
-// clean here and breaks ngc downstream. RN's declared shape also lists only the two
-// get/setGlobalHandler members, not reportError, which the polyfill does install.
+// Read off globalThis via Reflect, not a named identifier or an ambient declare: react-native
+// ships its own `ErrorUtils` global type, so redeclaring it here breaks any package whose tsconfig
+// pulls in RN's types. RN's declared shape also omits reportError, which the polyfill installs.
 function nativeReporter() {
     const utils = Reflect.get(globalThis, 'ErrorUtils');
     if (typeof utils !== 'object' || utils === null)
@@ -54,8 +41,7 @@ export function reportUncaughtError(value, info) {
     const report = nativeReporter();
     if (report !== null) {
         // Exactly one channel, never both: RN routes console.error into LogBox as well, so logging
-        // here too would double-report every error. Upstream returns false from showErrorDialog for
-        // this same reason (Libraries/Core/ReactFiberErrorDialog.js:57).
+        // here too would double-report every error.
         report(error);
         return;
     }

package/build/settings/index.android.d.ts

@@ -0,0 +1,6 @@
+export declare const Settings: {
+    get(_key: string): unknown;
+    set(_settings: Record<string, unknown>): void;
+    watchKeys(_keys: string | string[], _callback: () => void): number;
+    clearWatch(_watchId: number): void;
+};

package/build/settings/index.android.js

@@ -0,0 +1,21 @@
+// Settings, Android build: RN's SettingsFallback (Settings.js resolves to it off iOS). Android has
+// no SettingsManager, so every call warns and does nothing — no JS snapshot, no watchers. The
+// warning is RN's own user-facing one, not a diagnostic log.
+const UNSUPPORTED = 'Settings is not yet supported on this platform.';
+const NO_WATCH_ID = -1;
+export const Settings = {
+    get(_key) {
+        console.warn(UNSUPPORTED);
+        return null;
+    },
+    set(_settings) {
+        console.warn(UNSUPPORTED);
+    },
+    watchKeys(_keys, _callback) {
+        console.warn(UNSUPPORTED);
+        return NO_WATCH_ID;
+    },
+    clearWatch(_watchId) {
+        console.warn(UNSUPPORTED);
+    },
+};

package/build/settings/index.d.ts

@@ -1,8 +1 @@
-declare class SettingsImpl {
-    get(key: string): unknown;
-    set(settings: Record<string, unknown>): void;
-    watchKeys(keys: string | string[], callback: () => void): number;
-    clearWatch(watchId: number): void;
-}
-export declare const Settings: SettingsImpl;
-export {};
+export * from './index.ios';

package/build/settings/index.ios.d.ts

@@ -0,0 +1,8 @@
+declare class SettingsImpl {
+    get(key: string): unknown;
+    set(settings: Record<string, unknown>): void;
+    watchKeys(keys: string | string[], callback: () => void): number;
+    clearWatch(watchId: number): void;
+}
+export declare const Settings: SettingsImpl;
+export {};