Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

macOS test app is blocked on react-native-macos ≥ 0.82 (Hermes static_h build scripts)

Offen
  • Stimmt etwas nicht?
#392 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

@kraenhansen arbeitet bereits daran.

Seit 10.8.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

Apple 🍎 CI MacOS 💻

Tracking the Test app (macOS) failure on #372 ("Adopt Hermes' first-party Node-API (static_h)"), and the conditions under which the macOS job can be re-enabled.

Status

The MacOS 💻 label has been removed from #372, so Test app (macOS) no longer runs there. macOS is knowingly deferred — everything else in that PR (iOS, Android, the Node.js tooling) is unaffected.

Why it fails

#372 vendors Hermes from facebook/hermes static_h (pinned SHA) and lets React Native build it from source via REACT_NATIVE_OVERRIDE_HERMES_DIR. On iOS that's RN 0.88.0-nightly, whose Hermes build scripts match. On macOS the app is scaffolded by scripts/init-macos-test-app.ts against [email protected] / [email protected], and RN 0.81's Hermes build scripts predate the static_h changes we depend on:

  1. [RN] [1] Build Hermesc fails immediately. RN 0.81's sdks/hermes-engine/utils/build-hermesc-xcode.sh invokes cmake -S … -B … -DJSI_DIR=… with no -DCMAKE_BUILD_TYPE, and wraps it in env -i, so nothing can be injected from the outside. The pinned Hermes hard-errors in its root CMakeLists.txt:

    CMake Error at CMakeLists.txt:46 (message):
  Please set CMAKE_BUILD_TYPE

    Reproduced locally against the pinned SHA with [email protected]'s ReactCommon/jsi: configure fails as above, and succeeds once -DCMAKE_BUILD_TYPE=Release is added. Upstream RN added that flag in 0.82.0.

  2. [RN] [2] Build Hermes would fail next. RN 0.81's build-hermes-xcode.sh builds --target libhermes and copies API/hermes/hermes.framework. In the pinned Hermes the target is hermesvm and the bundle is lib/hermesvm.framework (same rename we handled for Android in #372). RN main was updated for this; 0.81 was not.

  3. Likely next: JSI header skew. #372 drops the step that copied Hermes' JSI headers into RN's ReactCommon/jsi, on the grounds that the pinned Hermes and RN 0.87+ agree. RN 0.81 does not, so the host module's use of IHermes / getVMRuntimeUnsafe() may not compile even once (1) and (2) are past.

Note: the second failed phase in CI ([CP] Copy XCFrameworks for weak-node-api) is most likely collateral — an earlier run with the same Hermesc error reported that phase as passing. Confirm rather than assume once the build gets further.

What gates re-enabling macOS

react-native-macos must ship a release based on React Native ≥ 0.82 (that release carries both the CMAKE_BUILD_TYPE fix and the hermesvm rename). Today latest is 0.81.9, next is 0.81.0, nightly is 0.78.4 — there is no 0.82+ line at all, so bumping the pin within 0.81.x buys nothing.

When that lands:

  1. Bump REACT_NATIVE_MACOS_VERSION / REACT_NATIVE_VERSION in scripts/init-macos-test-app.ts (they are peer-locked; keep them in lockstep).
  2. Re-add the MacOS 💻 label to the relevant PR — the job in .github/workflows/check.yml is already label-gated, so no workflow change is needed.
  3. Expect to work through (3) above: JSI/IHermes compatibility against the newer react-native-macos.

A local workaround is possible in the meantime (patch react-native-macos's two Hermes scripts from vendor-hermes), but it papers over a gap that keeps widening with every further static_h change, and does nothing about (3). Preferred order is: wait for upstream, then bump.

Related: #372, #391 (captures the raw xcodebuild log so a script phase failure is diagnosable at all).

Vorherrschende Sprache
TypeScript
Sterne
191
Forks
10
Ø Merge
2 T. 17 Std.
Gemergte PRs (30 T.)
3

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus callstackincubator/react-native-node-api

Alle Issues in callstackincubator/react-native-node-api

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.