fix(iOS): stage Hermes headers in prebuild compose job so ReactNativeHeaders resolves <hermes/...>#57661
Open
chrfalch wants to merge 1 commit into
Open
fix(iOS): stage Hermes headers in prebuild compose job so ReactNativeHeaders resolves <hermes/...>#57661chrfalch wants to merge 1 commit into
chrfalch wants to merge 1 commit into
Conversation
…Headers resolves <hermes/...>
The iOS prebuild workflow splits into two jobs on separate runners.
`build-rn-slice` stages the hermes-ios headers during setup
(`.build/artifacts/hermes/destroot/include/hermes`) but never hands them
to the `compose-xcframework` job. Compose (`-c` -> `buildXCFrameworks`)
computed the hermes include path from a directory that never exists on the
compose runner, silently got `null`, and skipped the hermes-header fold in
`headers-compose.js`. The published ReactNativeHeaders.xcframework therefore
shipped without `hermes/`, so consumers couldn't resolve `<hermes/...>`. No
warning fired, so every nightly regressed silently.
Fix (build-time, matches the artifact's self-contained design):
- compose-xcframework now re-stages the hermes-ios headers before composing
("Set Hermes version" + "Stage Hermes headers"), guarded by the same
cache-hit condition as its sibling steps.
- Extract the hermes-header resolution into an exported
`resolveHermesHeaders(buildFolder, required)` with a `findFirst` fallback,
and fail closed (throw) when a version-stamped CI cut can't find the
headers instead of shipping without them. Gated behind a new
`--require-hermes` flag, passed by the workflow only when `version-type`
is set (local dev keeps the previous no-fold behavior).
Adds unit tests for the resolver (found / findFirst fallback /
absent-not-required -> null / absent-required -> throws).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
meta-cla
Bot
added
the
CLA Signed
facebook-github-tools
Bot
added
the
Shared with Meta
cipolleschi
approved these changes
Jul 24, 2026
|
@cipolleschi has imported this pull request. If you are a Meta employee, you can view this in D113554720. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The iOS prebuild workflow (
.github/workflows/prebuild-ios-core.yml) splits into two jobs on separate runners:build-rn-slicestages the hermes-ios headers during setup (.build/artifacts/hermes/destroot/include/hermes), but uploads only.build/headers+ the SPM Products — not the hermes artifact.compose-xcframework(fresh runner) runs the compose (-c→buildXCFrameworks), which computed the hermes include path from.build/artifacts/hermes/destroot/include. That directory never exists on the compose runner, sohermesHeadersresolved tonulland the hermes-header fold inheaders-compose.jswas silently skipped.Net effect: the published
ReactNativeHeaders.xcframeworkshipped without thehermes/namespace, so consumers (e.g. Expo prebuilt) couldn't resolve<hermes/...>. Because the value wasnullrather than a bad path, not even the existing warning fired — every nightly regressed silently.Fix
Build-time staging, matching the artifact's self-contained design (the orphaned consumer-side sidecar + health check in
download-spm-artifacts.jsconfirm the bake was intended to happen at compose time):compose-xcframeworknow re-stages the hermes-ios headers before composing — aSet Hermes versionstep ($GITHUB_ENVdoesn't cross jobs) and aStage Hermes headersstep that extracts the tarball into.build/artifacts/hermes. Both are guarded by the samecache-hitcondition as the sibling steps.resolveHermesHeaders(buildFolder, required)with afindFirstfallback (mirroring the consumer-side stager). When a version-stamped CI cut can't find the headers it now throws instead of silently shipping withouthermes/. Gated behind a new--require-hermesflag, which the workflow passes only whenversion-typeis set — so local-ckeeps the previous no-fold behavior.Changelog:
[IOS] [FIXED] - Prebuilt
ReactNativeHeaders.xcframeworknow ships the Hermes public headers so consumers resolve<hermes/...>out of the boxTest plan
resolveHermesHeaders(__tests__/xcframework-test.js): resolves at the standard path, resolves via thefindFirstfallback, returnsnullwhen absent + not required, throws when absent + required.yarn jest packages/react-native/scripts/ios-prebuild/__tests__/xcframework-test.js --no-cache -i→ 4/4 pass (red before the resolver was exported).🤖 Generated with Claude Code