@gjsify/react-native 0.51.1 → 0.52.0

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/react-native",
-    "version": "0.51.1",
+    "version": "0.52.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.51.1",
-        "@gjsify/gtk-host": "^0.51.1"
+        "@gjsify/adwaita-app": "^0.52.0",
+        "@gjsify/gtk-host": "^0.52.0"
     },
     "peerDependencies": {
         "@react-navigation/core": "^7.21.13",
@@ -148,13 +148,13 @@
         }
     },
     "devDependencies": {
-        "@girs/adw-1": "5.0.0",
-        "@girs/gdk-4.0": "5.0.0",
-        "@girs/gjs": "5.0.0",
-        "@girs/gtk-4.0": "5.0.0",
-        "@gjsify/cli": "^0.51.1",
-        "@gjsify/rolldown-plugin-gjsify": "^0.51.1",
-        "@gjsify/unit": "^0.51.1",
+        "@girs/adw-1": "5.4.0",
+        "@girs/gdk-4.0": "5.4.0",
+        "@girs/gjs": "5.4.0",
+        "@girs/gtk-4.0": "5.4.0",
+        "@gjsify/cli": "^0.52.0",
+        "@gjsify/rolldown-plugin-gjsify": "^0.52.0",
+        "@gjsify/unit": "^0.52.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 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."
+            "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 steps are NOT gating there — on win32 this package's step and @gjsify/gtk-host's are both continue-on-error probes, so every number below is printed by report-probe-outcome.mjs as a job-summary row plus a ::warning:: annotation and fails nothing; only the closure steps above can red that job, and its green colour means the closure staged, verified and LOADED. 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 — as a probe — against a GATING 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",