Replies: 2 comments 5 replies
-
Bundled Hermes on AndroidHi all, What has changedWe changed the way how Hermes is built and distributed. Starting with React Native 0.69.0, every version of React Native will be built alongside to a Hermes version. This will make sure that the version of Hermes that has been built when RN was released, is fully compatible with that RN version. Historically, we had problems with matching versions of Hermes with versions of RN. This fully eliminates this problem and will ideally offer a bundled JS engine that is compatible with the specific RN version. How this will impact meOn Android, we're going to update the dependencies {
// ...
if (enableHermes) {
+ implementation("com.facebook.react:hermes-engine:+") {
+ exclude group:'com.facebook.fbjni'
+ }
- def hermesPath = "../../node_modules/hermes-engine/android/";
- debugImplementation files(hermesPath + "hermes-debug.aar")
- releaseImplementation files(hermesPath + "hermes-release.aar")
} else {
implementation jscFlavor
}
}Practically speaking, you won't be consuming Why this has changedAs mentioned, we're not building a version of Hermes together with React Native. Both Hermes and React Native, share the JSI code (here and here). To overcome this problem, we're now downloading the Hermes source code at build time, and making sure only one copy of JSI is used when building Hermes. How can I test this right now if I wish?The latest nightly of React Native (0.0.0-20220316-2009-8200f9159), contains a bundled version of Hermes. You shoudl be able to test it with:
Feel free to report any bug you might face, your feedback is deeply appreciated. Can I still use another engine?Yes, you can still use the Please note that, at the time of writing, the default for Information for ContributorsIf you're a React Native contributor or you're building an extension for Hermes, please read further as we expalin how this mechanism works. If you're a user of React Native, those information won't be relevant for you. How is this mechanism working?This mechanism relies on downloading a tarball from the facebook/hermes repository inside the facebook/react-native repository. We have a similar mechanism in place for other dependencies (Folly, Glog, etc.) This allows us to "similate" a monorepo setup in the OpenSource space. How is the version of Hermes picked?When building React Native from When cuttin a release branch for RN, we will be tagging a version of Hermes(with this GH Action https://github.com/facebook/hermes/blob/main/.github/workflows/create-tag.yml). This tag name will then be stored inside the Moreover, this approach allows us to tag a subsequent version of Hermes, should we need a patch once we're inside the RN release process. In a sense, you can think of this approach similarly to a git submodule. If you're building on top of Hermes, you can rely on those tags to understand which version of Hermes was used when building React Native. I'm afraid this change is impacting me.I'd like to stress that this is essentially an organizational change on "where" Hermes is built and "how" the code is syncronized between the two repos. The change should be fully transparent to our users. Historically, we used to cut a release of Hermes for a specific version of RN. In the new approach, you will instead have a tag that will represent the version of RN that was cut. Feel free to share your feedback and opinion in the thread below Android implementation detailsTo implement this on Android, we've added a new build inside the See here for more context: You can now fire a build of Hermes engine by invoking: (this will create a debug build of Hermes). Please note that now you'll need to have installed If you're wondering why the:
Line is needed. React Native is consuming fbjni using the non-prefab approach (i.e. unzipping the .aar). Hermes-engine, and other libraries, are using prefab instead to consume fbjni. We're looking into fixing this here so the Hermes import will be a oneliner. If you're wondering why we moved from If you have any questions/doubts on the approach, feel free to ask here 👍 EDIT: Added the "Information for Contributors" section |
Beta Was this translation helpful? Give feedback.
-
|
This is great to hear! I have a couple of questions on this:
|
Beta Was this translation helpful? Give feedback.
-
Yes, namely we're going to update the dependencies {
// ...
+ hermesImplementation(":ReactAndroid:hermes-engine")
- def hermesPath = '$projectDir/../../../../../node_modules/hermes-engine/android/'
- hermesDebugImplementation files(hermesPath + "hermes-debug.aar")
- hermesReleaseImplementation files(hermesPath + "hermes-release.aar")You could try it right now if you clone
Yes, we're going to share more in the coming future about Hermes & iOS. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing this. I think this makes a lot of sense. I imagine this will also make it easier to test changes to Hermes in the context of a React Native app. A bit related: We're are faced with a similar issue which we need to address at some point: We're currently pre-building our binary, but can't actually rely on the JSI ABI to remain stable across React Native versions. |
Beta Was this translation helpful? Give feedback.
-
|
The set of tarballs is a projection of the state of the Hermes OSS repo. Q: is projection always along Hermes main branch? There is a separate model of repository projection used by Yoga. It exists as its own GitHub repo, but also is projected into the C++ source tree of the I am unfamiliar about how Meta internally has this projection set up, but projecting source to the repo has some properties that I think would work well here. It means that React Native's existing repo-versioning would allow servicing cherry-pick style changes to Hermes sources, at the same cadence as RN itself. It would also allow RN users/redistributors (like RNW) to leverage their existing systems to build cryptographically signed binaries from RN sources. Downloading unique tarballs or zip files during the build is a reality we have, but I've seen them often have a negative impact to build determinism or performance compared to rolling the sources into an already used package manager. E.g. inlining into the C++ source distributed as part of the existing NPM package, or separating into published artifacts. I'm curious why the format was chosen compared to alternatives. |
Beta Was this translation helpful? Give feedback.
-
Sorry I forgot to answer this. The answer is no. I've update my comment with a section for contributors that explains the setup in details and clarifies (hopefully) most of the doubts. Let me know if it's not clear. |
Beta Was this translation helpful? Give feedback.
-
|
Hey all, |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I'm opening this discussion to discuss the implication of having Hermes as default engine for the New RN Architecture.
As part of the New Architecture Rollout, we're going to set Hermes as the default engine for all the new React Native applications. It will still be possible to use other JS engines with your application, but we expect to develop new features and provide better support having a Hermes-first approach.
Feel free to ask your questions/ideas/doubts related to this in this discussion.
Relevant resources
Beta Was this translation helpful? Give feedback.
All reactions