@gjsify/react-native 0.47.0 → 0.49.0

package/lib/types/support-table.d.ts

@@ -120,7 +120,7 @@ export { OWN_EXPORT_NAMES };
  * falls through to the layer's own exports — and only on the ROOT surface, because
  * `configureStyle` is exported from `@gjsify/react-native` and from nowhere else.
  * That order is the safety property: the derived list can add names, never promote a
- * `planned` one, so a mistake upstream of it cannot turn `import { Modal }` into a
+ * `planned` one, so a mistake upstream of it cannot turn an import of one into a
  * green build.
  *
  * A name in NEITHER population is still refused — which is the whole difference

package/lib/types/window-chrome.d.ts

@@ -0,0 +1,39 @@
+import Gtk from 'gi://Gtk?version=4.0';
+import { type ReactElement, type ReactNode } from 'react';
+/** The window's header bar, as something a tree can take over. */
+export interface WindowChrome {
+    /**
+     * Take the window's header bar out, and get the undo.
+     *
+     * `claimant` is only for the refusal message — it is what a reader needs to find
+     * the second navigator.
+     */
+    claim(claimant: string): () => void;
+}
+/** The widgets `AppRegistry` puts in a window, and the chrome hand-over for them. */
+export interface WindowShell {
+    /** What goes into `Gtk.Window.set_content`. */
+    readonly root: Gtk.Widget;
+    /** What React renders into. */
+    readonly content: Gtk.Widget;
+    /** The hand-over for the header bar in `root`. */
+    readonly chrome: WindowChrome;
+}
+/**
+ * The ordinary Adwaita shell: a toolbar view, a header bar, and a box to render into.
+ *
+ * A function rather than four lines inside `buildWindow`, because the router's own
+ * vectors have to measure THIS composition — a spec that rebuilt it by hand would
+ * pass while the shipping shell drifted.
+ */
+export declare function buildWindowShell(): WindowShell;
+/** Publish the window's chrome to the tree rendered into it. */
+export declare const provideWindowChrome: (chrome: WindowChrome, children: ReactNode) => ReactElement;
+/**
+ * The window's chrome, or `null` when nobody published one.
+ *
+ * `null` is an ORDINARY answer, not a fault: a consumer who builds their own window
+ * and renders a React root into it publishes nothing, and then there is no default
+ * bar to step aside for — their window, their chrome.
+ */
+export declare const useWindowChrome: () => WindowChrome | null;

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/react-native",
-    "version": "0.47.0",
+    "version": "0.49.0",
     "description": "The React Native view vocabulary rendered onto GTK4/Adwaita, over @gjsify/gtk-host",
     "type": "module",
     "module": "lib/esm/index.js",
@@ -120,8 +120,8 @@
         "react-native"
     ],
     "dependencies": {
-        "@gjsify/adwaita-app": "^0.47.0",
-        "@gjsify/gtk-host": "^0.47.0"
+        "@gjsify/adwaita-app": "^0.49.0",
+        "@gjsify/gtk-host": "^0.49.0"
     },
     "peerDependencies": {
         "@react-navigation/core": "^7.21.13",
@@ -152,9 +152,9 @@
         "@girs/gdk-4.0": "4.6.0",
         "@girs/gjs": "4.6.0",
         "@girs/gtk-4.0": "4.6.0",
-        "@gjsify/cli": "^0.47.0",
-        "@gjsify/rolldown-plugin-gjsify": "^0.47.0",
-        "@gjsify/unit": "^0.47.0",
+        "@gjsify/cli": "^0.49.0",
+        "@gjsify/rolldown-plugin-gjsify": "^0.49.0",
+        "@gjsify/unit": "^0.49.0",
         "@react-navigation/core": "^7.21.13",
         "@react-navigation/routers": "^7.6.4",
         "@types/node": "^25.9.2",
@@ -173,7 +173,7 @@
         },
         "osNotes": {
             "darwin": "Platform.OS reads the host OS, so this package owes an OS claim (ADR 0018). MEASURED 2026-08-31 by gtk-os-suites.yml on darwin-arm64 (macOS 26.5.2) and darwin-x64 (macOS 15.7.9), on Node against the published @gjsify/gtk-runtime-darwin-* closure with no Homebrew GTK on the host — the combination ADR 0024 § 4 puts a shipped .app on. The layer this package renders through, @gjsify/gtk-host, is GATING and green there: 2274 of 2274 on both arches. Its OWN suite ran as a probe and reported 2 of 857 on each arch — BY NAME the same two that failed on Linux under the node target (#1438), so darwin added nothing to that set. #1438 is now CLOSED in the engine — node-gi realizes a classed GType on the `$gtype` read and runs a class-struct static on the class it was CALLED on — and the Linux node leg measures 1222 of 1222. This leg does NOT yet, and the reason is the pairing rather than the operating system: the fix is in the addon's C++, and gtk-os-suites.yml installs the PUBLISHED `@gjsify/node-gi` prebuild here on purpose (ADR 0024 § 4 asks what a stranger's download does). MEASURED at the same commit on 2026-09-02: 1 of 1220 on both darwin arches against 1222 of 1222 on Linux with a locally built addon — the same `popped` assertion, the one #1438 fixed. So the step stays a probe and this claim stays `partial` until the first release carrying that engine fix; promote on the first run after it where the only failures left are darwin's own. Nothing else is known to stand in the way: the widgets are GTK4/Adwaita and the style partition is pure TS.",
-            "win32": "As darwin for why a claim is owed, and one step further: there is no GJS host on Windows at all (ADR 0024 § 4), so the only route is Node + @gjsify/node-gi + @gjsify/gtk-runtime-win32-x64 — which gtk-os-suites.yml installs from npm and MEASURED on 2026-08-31. The closure is sound and GATING: the published bundle verifies (33 backed typelibs, windowing=true, decode probe) and check-batteries.mjs loads Gtk + Adw with no gvsbuild GTK on the host. The suite reported 7 of 848 — and that NUMBER is the misleading part, so here is its attribution: 2 were the #1438 baseline that was red on every OS and 1 a knock-on of one of them (the same `popped` seam), all three CLOSED in the engine since — and still counted on this leg, which runs the PUBLISHED addon and so cannot see an unreleased C++ fix (measured, same as darwin, 2026-09-02); 2 are inherited from @gjsify/gtk-host's table declaring GTK's Unix print stack (#1446, and gtk-host itself is 6 of 2264 there against 2274/2274 on both darwin arches), and 2 are POSIX-shaped ASSERTIONS rather than defects: the Image/ImageBackground vectors round-trip '/nonexistent-gjsify-vector.png' through Gio.File.new_for_path (src/components.ts) and assert get_path() returns it unchanged, but get_path() answers the NATIVE path, so GLib correctly returns '\\\\nonexistent-gjsify-vector.png'. The URI reading is excluded by the code: the assertion calls get_path(), not get_uri(). So this layer's own win32-specific defect count is ZERO, and `partial` records unmeasured ground rather than a Windows wall. Only win32-x64 is measurable at all — gvsbuild publishes no arm64 GTK. Promote when the engine fix for #1438 is released, #1446 closes and the two assertions stop being POSIX-shaped."
+            "win32": "As darwin for why a claim is owed, and one step further: there is no GJS host on Windows at all (ADR 0024 § 4), so the only route is Node + @gjsify/node-gi + @gjsify/gtk-runtime-win32-x64 — which gtk-os-suites.yml installs from npm and MEASURED on 2026-08-31. The closure is sound and GATING: the published bundle verifies (33 backed typelibs, windowing=true, decode probe) and check-batteries.mjs loads Gtk + Adw with no gvsbuild GTK on the host. The suite reported 7 of 848 — and that NUMBER is the misleading part, so here is its attribution: 2 were the #1438 baseline that was red on every OS and 1 a knock-on of one of them (the same `popped` seam), all three CLOSED in the engine since — and still counted on this leg, which runs the PUBLISHED addon and so cannot see an unreleased C++ fix (measured, same as darwin, 2026-09-02); 2 are inherited from @gjsify/gtk-host's table declaring GTK's Unix print stack (#1446, and gtk-host itself is 6 of 2264 there against 2274/2274 on both darwin arches), and 2 were POSIX-shaped ASSERTIONS rather than defects — the Image/ImageBackground vectors round-tripped '/nonexistent-gjsify-vector.png' through Gio.File.new_for_path (src/components.ts) and asserted get_path() returned it unchanged, but get_path() answers the NATIVE path, so GLib correctly returned '\\\\nonexistent-gjsify-vector.png'. FIXED in #1556: both now compare with Gio.File.equal plus the basename, which is the same claim in every separator. Fixing them found a real win32 defect beside them, also fixed there: normaliseSource read a DRIVE LETTER as a URI scheme (RFC 3986 admits a single ALPHA), so 'C:\\\\images\\\\logo.png' was refused as a 'c:' URI on the one OS that spells absolute paths that way. So this layer's own win32-specific defect count is ZERO, and `partial` records unmeasured ground rather than a Windows wall. Only win32-x64 is measurable at all — gvsbuild publishes no arm64 GTK. Promote when the engine fix for #1438 is released and #1446 closes; the assertions are no longer in the way."
         },
         "runtimes": {
             "gjs": "polyfill",

package/react-native-surface.json

@@ -2,15 +2,19 @@
     "$comment": [
         "The public export names of react-native, read from the installed package's index.js",
         "rather than from documentation. src/support-table.ts must have exactly these keys.",
+        "SORTED, so a version bump diffs as the names that changed rather than as the order",
+        "upstream happens to declare them in. The comparison is set-based either way.",
+        "ONE VERSION IN THE TREE: this records the release the workspace RESOLVES, so the",
+        "drift half of scripts/check-rn-surface.mjs compares like with like and fails on a",
+        "real difference. When the two do diverge -- someone bumps the dev dependency and",
+        "forgets this file -- the check prints both versions and the difference between the",
+        "releases rather than failing, because that is what it is.",
         "Committed rather than derived at check time because react-native pulls ~170 MB of",
         "dependencies (hermes-compiler alone is 47 MB) and every workspace install would pay it",
-        "for one list of strings. scripts/check-rn-surface.mjs compares the table against this",
-        "file always, and additionally re-derives this file from a real react-native install",
-        "when one is resolvable -- so the gate is stronger where the package is present and says",
-        "so where it is not."
+        "for one list of strings."
     ],
-    "reactNativeVersion": "0.85.3",
-    "readOn": "2026-08-26",
+    "reactNativeVersion": "0.87.1",
+    "readOn": "2026-09-04",
     "exports": [
         "AccessibilityInfo",
         "ActionSheetIOS",
@@ -20,6 +24,7 @@
         "AppRegistry",
         "AppState",
         "Appearance",
+        "AssetRegistry",
         "BackHandler",
         "Button",
         "Clipboard",
@@ -37,7 +42,6 @@
         "Image",
         "ImageBackground",
         "InputAccessoryView",
-        "InteractionManager",
         "Keyboard",
         "KeyboardAvoidingView",
         "LayoutAnimation",
@@ -46,7 +50,6 @@
         "Modal",
         "NativeAppEventEmitter",
         "NativeComponentRegistry",
-        "NativeDialogManagerAndroid",
         "NativeEventEmitter",
         "NativeModules",
         "Networking",
@@ -73,7 +76,6 @@
         "Text",
         "TextInput",
         "ToastAndroid",
-        "Touchable",
         "TouchableHighlight",
         "TouchableNativeFeedback",
         "TouchableOpacity",
@@ -93,11 +95,18 @@
         "processColor",
         "registerCallableModule",
         "requireNativeComponent",
+        "unstable_DEFAULT_INITIAL_NUM_TO_RENDER",
         "unstable_NativeText",
         "unstable_NativeView",
         "unstable_TextAncestorContext",
+        "unstable_VirtualArray",
+        "unstable_VirtualColumn",
+        "unstable_VirtualColumnGenerator",
+        "unstable_VirtualRow",
         "unstable_VirtualView",
         "unstable_batchedUpdates",
+        "unstable_createVirtualCollectionView",
+        "unstable_getScrollParent",
         "useAnimatedColor",
         "useAnimatedValue",
         "useAnimatedValueXY",