Repository navigation
Pick hermesc the same way React Native does - #58
Open
revopushbot wants to merge 3 commits into
Open
revopushbot wants to merge 3 commits into
revopushbot wants to merge 3 commits into
Conversation
The CLI could compile a release with a different hermesc than the store
binary, producing bytecode the app can't load. Mirror React Native's
lookup order:
- Android (gradle-plugin detectOSAwareHermesCommand): literal
`hermesCommand` from the `react { }` block or legacy project.ext.react,
REACT_NATIVE_OVERRIDE_HERMES_DIR / hermesc built from source, then
hermes-compiler when hermesV1Enabled=true, else sdks/hermesc, else
hermes-compiler.
- iOS (react-native-xcode.sh): HERMES_CLI_PATH, the CocoaPods
hermes-engine hermesc, then hermes-compiler.
- Resolve hermes-compiler through react-native so non-hoisted installs
are found.
Previously sdks/hermesc always won, so RN 0.82 apps with Hermes V1 and
iOS apps whose CocoaPods Hermes differs from npm got the wrong compiler.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…n-order # Conflicts: # script/react-native-utils.ts
- Resolve a relative `react { hermesCommand }` against react.root (the
project root), as BundleHermesCTask runs hermesc from there; legacy
project.ext.react stays relative to the app module. Expand $rootDir
and $projectDir.
- Kotlin DSL build scripts that set hermesCommand are evaluated with the
Gradle wrapper (reusing the version-detection init script, now
generalized to print any JSON); on failure, warn and fall back to the
default hermesc.
- iOS: read HERMES_CLI_PATH from ios/.xcode.env(.local) too (and load
.xcode.env, which was never read), and without Pods prefer
sdks/hermesc unless RCT_HERMES_V1_ENABLED=1.
- Reuse file-utils fileExists and simplify the lookup code.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
1 participant
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.
Problem
release-react/release-expomust compile with the samehermescas the store build. Otherwise the update contains bytecode the app's Hermes runtime can't load. The CLI always preferredreact-native/sdks/hermesc, which differs from React Native's own lookup:hermesV1Enabled=true: the app useshermes-compiler(Hermes V1, bytecode v98), but the CLI compiled withsdks/hermesc(v96).HERMES_CLI_PATHand the CocoaPodshermes-enginehermesc. React Native's ownreact-native-xcode.shwarns that the CocoaPods Hermes "may legitimately differ" from npmhermes-compiler.hermesCommand: the CLI only read the legacyproject.ext.reactform (RN < 0.71), not the currentreact { hermesCommand = ... }block, and checkedsdks/hermescbefore it.REACT_NATIVE_OVERRIDE_HERMES_DIR/ Hermes built from source: ignored.hermes-compilernot hoisted (installed underreact-native/node_modules): not found, so the CLI fell through to a path that doesn't exist.New lookup order
Android, following
detectOSAwareHermesCommandin the gradle plugin:hermesCommandfromreact { }orproject.ext.react, with%OS-BIN%substituted and resolved against the app module. Groovy expressions, such as Expo's computed path, can't be evaluated and are skipped. React Native's default order lands on the same compiler for those.REACT_NATIVE_OVERRIDE_HERMES_DIR/build/bin/hermesc, or Hermes built from source inReactAndroid.hermesV1Enabled=true:hermes-compiler, thensdks/hermesc. Otherwisesdks/hermesc, thenhermes-compiler.iOS, following
react-native-xcode.sh:HERMES_CLI_PATH.<Podfile dir>/Pods/hermes-engine/destroot/bin/hermesc.hermes-compiler, thensdks/hermesc.After both lists come the existing legacy fallbacks: the
hermes-enginepackage, thenhermesvm.hermes-compileris now resolved through react-native (require.resolve(..., { paths: [reactNativeDir] })), which is the same approach Expo SDK 55 andreact-native-xcode.shuse.What React Native ships
sdks/hermeschermes-compilerdependency0.0.0, an empty placeholder; a V1 opt-in overrides it0.14.1(v96)250829098.x, Hermes V1 (v98)Testing
test/hermes-command.tsbuilds fake project layouts for each case: literalreact { }command, Expo expression skipped, V1 flag, non-hoistedhermes-compiler,REACT_NATIVE_OVERRIDE_HERMES_DIR, iOSHERMES_CLI_PATH, CocoaPods compiler, and iOS without CocoaPods.react-native/packages/helloworld), both platforms still resolve to itssdks/hermesc.tscpasses, and the release flow tests pass.Related: #57, which detects bytecode version mismatches against the base release.
🤖 Generated with Claude Code