Skip to content

Road to 0.69.0 #21

cortinico started this conversation in Releases
Road to 0.69.0 #21
Apr 28, 2022 · 26 comments · 133 replies

cortinico
Apr 28, 2022
Maintainer

The branch cut has happened.

Notice

Highlighted Changes in this release

A full detail of the release changes is available in the Changelog PR

React Native 0.69.0 will contain some significant changes that we would love to ask release testers to try.

Hermes Distribution Model

React Native 0.69.0 contains changes to how Hermes is distributed to you. The change will improve the general stability of the Engine and will make sure you're a consuming a engine that is fully compatible with a specific React Native version. This change is described here in detail.

How to test Enable Hermes following the usual instructions here https://reactnative.dev/docs/next/hermes and report any issue you're facing for Hermes in this discussion.

React 18 & Concurrent React

React Native 0.69.0 will be the first version of React Native to ship with React 18.
Users on the New Architecture, will be able to use the Concurrent React features.
By default, we're enabling Concurrent React features for users on the New Architecture.

More documentation on how to use Concurrent React within React Native can be found here.

How to test Create a React Native app enabling the New Architecture. Toggle the concurrentRootEnabled method and report any issue you're facing to this discussion on the New Architecture Working Group.

New Architecture

We're continuing the rollout of the New Architecture, started in React Native 0.68.
Specific issues that are related to the New Architecture should be reported inside the New Architecture Working group. If you're not a member, you can request an invite here.

Release Process

Checklist

  • Changelog PR
  • Start a Google doc of blog post for release and invite contributors of release highlights to expand
  • Follow up on release dependencies

    When ready to publish stable

  • Ship changelog
  • Ship blog post
  • Notify react-native-website to ship new version

Retrospective Topics

Release Status

Tracking 0.69.0-rc.3

Blocking issues for releasing 0.69.0-rc.3

Picks for 0.69.0-rc.3

Tracking 0.69.0-rc.2

Blocking issues for releasing 0.69.0-rc.2

Picks for 0.69.0-rc.2

Hermes:

Tracking 0.69.0-rc.1

Blocking issues for releasing 0.69.0-rc.1

Picks for 0.69.0-rc.1

Replies

26 comments
·
133 replies

This comment was marked as off-topic.

@mikehardy

I do not believe statements like that are relevant for this issue?
This issue is for comments with pointers to commit hashes on main branch, or discussion around the same, to be picked to 0.69.0 in order to release it. And that's it

@raajnadar

@wibb36 this section has nothing to do with expo, if you want to discuss you can start a thread on https://github.com/expo/expo/discussions

Here the discussion should be limited to RN 0.69 release process. Expo team & react native team work independently.

This comment has been hidden.

@fortmarek

Hey @leotm, thanks for the heads-up - updated 👍

@Simek

FYI, the contribution related content is slowly moving to the React Native website, and will be removed from the wiki in the future. The matrix which this link refers to is now avaible here:

@fortmarek

Thanks for pointing that out @Simek, I created a PR for the minor release instructions.

pod install regression - something that worked in 0.68.1 is not working with no other change then to swicth npx react-native init to use --version 0.69.0-rc.0 - fully automated reproduction here, zoomed in the lines to toggle: https://github.com/mikehardy/rnfbdemo/blob/b647cb5d2e8bc955aa4dcf81b674d1a2c4aa8b6c/make-demo.sh#L52-L54

I'll update this mini-thread as I characterize it, but will only have time off and on, so I warmly welcome anyone else that might know of changes from 68 to 69 that would affect pod install taking a look

If no one else does, I'll figure out as I have time and post relevant PRs / commits as I have ability 😅

(also of course can post an issue in main repo and collapse this, if that's the best course - just thought a fuzzbust here might be most efficient)

9 replies
@tido64

Does this happen only when you do react-native init? I upgraded the react-native-test-app and it seems to be working without having to make any additional changes. So we can probably eliminate upgrading.

@mikehardy

Unknown, my first cut at release testing post-announcement on Discord is just to fire up the script and let it run :-). So, can only say, from init this is a problem. Unsure on upgrade of existing. Also, this may be react-native-firebase ruby coding on pod install using something internal and we need to forward-port or make more compatible or something.

@fortmarek

Hey @mikehardy 👋

Do you have any updates on this issue? If you could post the error here, that'd be also appreciated 🙌

This comment has been hidden.

@fortmarek

This does seem to be new - it has been introduced here. I'd think the warning should only be raised when Fabric is enabled - for Paper, the warning is not relevant.

@tido64

@cortinico: Can we remove it? This is not actionable when you're on Paper. It's just noise.

@Andarius

I don't know if it's related but a while back I asked for a more global way of removing log / warn. react-native-community/discussions-and-proposals#308. This could also be an option ?

About the Hermes building, I'm seeing very high time consumed compiling the Hermes-engine on the pod install step, on a MacBook Pro 2019 (intel) , i7 2.6Ghz and 32gb. How much time will it normally take from now on?

19 replies
@tomekzaw

Just for the record, on 8-core M1 Pro 14" connected to the power supply it takes between 40 and 55 minutes.

@kelset

oh wow 😱 @jacargentina are your times similar to @tomekzaw?

@jacargentina

@kelset yes; i think this way of compiling hermes will not be very popular 😏

This comment has been hidden.

@kelset

this can't happen directly because of the way react-native "packs" react - there's a PR in the works by @cortinico with the details facebook/react-native-website#3092 but yeah it's likely 18.1 won't be part of 0.69.
The changes seem to be mostly react-dom related anyway :)

This comment has been hidden.

@fortmarek

I raised a PR for this here.

@cortinico

cortinico May 4, 2022
Maintainer Author

Is this intentional? Should we sync the two?

Nope it was not. Thanks @fortmarek for sending the PR. Waiting for a new alpha of the CLI to land this inside RC1.

@fortmarek

Will be picked as a part of this commit.

This comment has been hidden.

@xiongemi

i got another issue, i ran RCT_NEW_ARCH_ENABLED=1 pod install

it got stuck

Downloading dependencies
Installing FBReactNativeSpec 0.69.0-rc.0
Installing RCT-Folly 2021.06.28.00-v2
Installing RNGestureHandler 2.4.1
Installing RNScreens 3.13.1
Installing React-Codegen 0.69.0-rc.0
Installing React-Fabric (0.69.0-rc.0)
Installing React-RCTFabric (0.69.0-rc.0)
Installing React-graphics (0.69.0-rc.0)
Installing React-hermes (0.69.0-rc.0)
Installing React-jsi 0.69.0-rc.0
Installing React-rncore (0.69.0-rc.0)
Installing hermes-engine (0.11.0)
@mikehardy

Never assume that which is working silently is stuck - I bet hermes-engine was just downloading and/or unpacking. It is a gigantic pod, and I've heard lots of people say pod install was stuck when they had not checked their network traffic where it was just maxed out downloading the thing

@tomekzaw

Once you add --verbose flag, you can see CMake compiling Hermes sources during Installing hermes-engine (0.11.0) phase.

cortinico
May 3, 2022
Maintainer Author

Sharing this from the React Native issue tracker:

We might have to look closely into this and work on a fix for it.

0 replies

This comment has been hidden.

@tido64

It was recently removed here: react-native-community/cli@25eec7c

@fortmarek

Given the bump in the React Native CLI as pointed out by @tido64, I'd say this issue is expected, will consider this to be resolved 🙂

This comment has been hidden.

@fortmarek

Added to the list of picks cc @cortinico 🚀

My apologies in advance if this is not the correct place for this but I encountered the following while upgrading to 0.69.0-rc.1. I don't mind moving this or parts of this to the correct location if needed.

OS: Void Linux
Kernel: 5.16.20_1

Not sure how useful this is but I had issues building Hermes after manually upgrading from 0.68.1 to 0.69.0-rc.1 by following https://react-native-community.github.io/upgrade-helper/?from=0.68.1&to=0.69.0-rc.0. As a side note I am also using the 0.68.1 TypeScript template.

1. The first issue was related to not enabling Hermes but it builds when the new architecture is enabled anyway. Not a huge problem as the docs above (reactwg/react-native-new-architecture#4) explain that Hermes is built with RN 0.69 and that ensures the versions are compatible. Maybe a note in the docs that this overrides the enableHermes config would prevent confusion since this is new.

2. The second issue that caused the first to be more of a confusion was that Hermes would fail to build and it was not immediately clear why as I could not find anyone else with this issue.

> Task :ReactAndroid:hermes-engine:configureBuildForHermes FAILED
CMake Deprecation Warning at CMakeLists.txt:42 (cmake_policy):
  The OLD behavior for policy CMP0026 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- The following ICU libraries were not found:
--   uc (required)
--   i18n (required)
--   data (required)
--   uc (required)
-- Failed to find all ICU components (missing: ICU_INCLUDE_DIR ICU_LIBRARY _ICU_REQUIRED_LIBS_FOUND) (Required is at least version "52")
CMake Error at CMakeLists.txt:520 (message):
  Unable to find ICU.

To fix this I installed icu-devel using sudo xbps-install icu-devel and added and environment variable ICU_ROOT=/usr/lib/icu to point to the icu-devel package.

I figured that much out by looking at https://github.com/facebook/hermes/blob/f11379f0564fd2b93a6024debffccd5eebce547e/CMakeLists.txt#L465 and seeing that it was expecting a ICU_ROOT variable.

Maybe another note could be added to the docs for Linux users that encounter this issue as building Hermes with React Native is new to 0.69. Or maybe this is a one off issue just for me. I saw that ICU is required for building Hermes but I did not see this issue in the Hermes repository. Should the Hermes build process contain ICU or download it for systems that don't already have ICU?

3. The last issue actually occurred prior to the Hermes issues but I saved it for last as it may not be related to this discussion. I kept getting:

> Task :ReactAndroid:generateCodegenArtifactsFromSchema FAILED

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.3.3/userguide/command_line_interface.html#sec:command_line_warnings
9 actionable tasks: 9 executed
Note: /share/projects/boilerplates/RN69/node_modules/react-native-gradle-plugin/src/main/java/com/facebook/react/codegen/generator/SchemaJsonParser.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
node:internal/modules/cjs/loader:936
  throw err;
  ^

Error: Cannot find module 'mkdirp'
Require stack:
- /share/projects/boilerplates/RN69/node_modules/react-native/scripts/generate-specs-cli.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/share/projects/boilerplates/RN69/node_modules/react-native/scripts/generate-specs-cli.js:23:16)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/share/projects/boilerplates/RN69/node_modules/react-native/scripts/generate-specs-cli.js'
  ]
}

I read on a related stack overflow question that this can be caused by having insufficient privileges but running again with sudo did not fix the issue.

To fix this issue I installed mkdirp and then the Hermes issues began.

I hope this is helpful.

6 replies
@cortinico

cortinico May 6, 2022
Maintainer Author

Thanks for those insights @chrayel

  1. What is the issue exactly.

  2. Looping @neildhar here as that should definitely not happen. We have a CMake checks that verifies if you have icu installed or not.

  3. I suppose you yarn install before building right? If so, that's something we should look into as we're experiencing the similar error on CI at the moment.

@neildhar

On 2, that's an interesting point. Hermes requires ICU to build on Linux and Windows, and should automatically find ICU if it is already installed on your system. (I believe it is always available on Windows, but I may be wrong)

Technically though, Hermes only needs ICU for building the VM, and not for building hermesc. So if we modify the build process, we could get away without ICU.

Concretely, there are 2 options:

  1. Require users to have ICU installed on their system when they build RN on Linux. This has the advantage of being fairly simple, and lines up with how Hermes is already built and tested, so it is unlikely to regress.
  2. Use the fact that we don't need ICU for hermesc to remove the dependency on ICU. To avoid changing the Hermes build scripts after the cut, a workaround for RN 0.69 is to pass in -DICU_FOUND=ON as an argument to CMake when configuring the hold build of hermesc. And then we can implement a proper solution in a later version, for example, by renaming the variable to something like ICU_NEEDED. This would work, but is a bit of a hack, because we're circumventing a check when configuring the build, and trying to build any other target will result in a link failure.
@chrayel

@cortinico No problem. I have never really participated in FOSS but since I felt that I ran into some new issues related to the new arch process, I figured I could share my experience. I am very appreciative of the work you guys do.

To explain my documentation related notes... Much of what I found was not very difficult to solve but might cause more headaches in the future if not documented visibly. I do believe that a great deal of effort is placed on documentation and this should not be received as a complaint. I am just passing along information gathered while testing 0.69 from my perspective.

  1. This issue dealt more with documentation as it was not clear to me at the time that Hermes is used as default for the new architecture. As in, when I see that enableHermes=false I did not understand why Hermes was being built. enableNewArch=true overrides enableHermes. That's all this was about. Again, sorry if it seems to be nit-picky but I'm just trying to give back what I can.

  2. @neildhar I agree and I believe your first option makes the most sense. Most Linux distros probably come with the needed ICU packages. I could not find the issue anywhere else and maybe this discussion will come up in the event someone does look up the specific error I received. Providing a bit of info in the building docs of Hermes could be helpful as well.

  3. I'm not sure what to think of this error. I installed via the template/npx and ran npm install again. It did not install any additional packages. After I install mkdirp, the build successfully finishes. After the first build, I am able to uninstall mkdirp and rerun build with no issues.

Steps I took to replicate 3:

  1. npx react-native init RN69Fresh --version 0.69.0-rc.0
  2. npx react-native start
  3. npx react-native run-android
  • Error: Cannot find module 'mkdirp'
  1. npm install mkdirp
  2. npx react-native start
  3. npx react-native run-android
  • Builds successfully
  1. npm uninstall mkdirp
  • Builds successfully

This comment was marked as off-topic.

@kelset

hey Michael, I appreciate your eagerness to be on the new architecture but there's no way support for the old architecture will drop this soon. In the coming months there are going to be official blogpost detailing how and when the old architecture will stop being supported, but you can expect it to be supported for at least the rest of this year

When upgrading from 0.68.1 to 0.69.0-rc.0 got:

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/mymac/Desktop/myapp/app/android/build.gradle' line: 48

* What went wrong:
A problem occurred evaluating root project 'myapp'.
> Project with path ':react-native-background-fetch' could not be found in root project 'myapp'.

Although the lib is apparently fine i removed it and then the same occurs but this time saying that the firebase lib could not be found in root project...

5 replies
@mikehardy

@joaotmachado that's not enough information to help, sorry. I work on both those libs and this error report would be rejected in those repos as lacking informaiton, with apologies
https://stackoverflow.com/help/how-to-ask
https://stackoverflow.com/help/minimal-reproducible-example

@cortinico

cortinico May 6, 2022
Maintainer Author

Build file '/Users/mymac/Desktop/myapp/app/android/build.gradle' line: 48

Knowing what's a line 48 of that file would be the bare minimum. The resources mentioned by @mikehardy would also be a valid addition 👍

@joaotmachado

@mikehardy just: "please provide me more information" would be a kinder reply (as saying in react native terms: Showing empathy towards other community members). Im doing my best to help. The issue is that first it (0.68.1) was running fine and after the upgrade to (0.69.0-rc.0 ) following the upgrade helper now its not. I will provide more information.

This comment has been hidden.

@mikehardy

This literally just bit me - that python was pulled in macOS 12.3 (on March 24th, if that jogs anyone's memory with regard to branch cuts etc). It will not be visible in macos-12 github runners, as they install python2 again on the image so any problems related to python interpreter missing will be masked even if you use macos-12 runners despite macos-11 runners being "macos-latest" and masking the problem also since they still have python 2 as default.

all macOS python scripts must use python3 now as the binary name I think, to reliably execute. Some scripts may need forward-porting, especially around string handling.

@Simon-TechForm did you chase into the relevant CMake file at all to see how it was executing Python? Have you tried (as a temporary test!) to see if a symbolic link from name python to binary /usr/bin/python3 on your system in your PATH somewhere works?

@leotm

i remember this biting similarly earlier
like @mikehardy suggested symlinking to python3 should work as a good temporarily test
or even hackier what i did - till the relevant updated landed

@leotm

since hermes-2022-04-28-RNv0.69.0 we rely on CMake 3.13.0
but we're still including FindPythonInterp from couple yrs ago where we also removed arg -DPYTHON_EXECUTABLE=python3

FindPythonInterp's been deprecated since CMake 3.12 - we should be using FindPython, FindPython2 and/or FindPython3 instead

This comment has been hidden.

@fortmarek

Thanks for the message @mikehardy! I agree, let's pick this once it's merged 🙌

@kelset

commit landed: facebook/react-native@d493f45

@kelset

great work everyone! 👏👏👏👏👏

tido64
May 12, 2022
Collaborator

pod install --project-directory=ios fails if Hermes is enabled because of hard-coded assumptions:

% pod install --project-directory=ios
[Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json
[Hermes] Extracting Hermes tarball (5244f8)

[DEBUG] pwd: /~/example
[DEBUG] cp: cp ../node_modules/react-native/sdks/hermes-engine.podspec ../node_modules/react-native/sdks/hermes/hermes-engine.podspec

warn Multiple Podfiles were found: ios/Podfile,macos/Podfile. Choosing ios/Podfile automatically. If you would like to select a different one, you can configure it via "project.ios.sourceDir". You can learn more about it here: https://github.com/react-native-community/cli/blob/master/docs/configuration.md
Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport
Analyzing dependencies
Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
[Codegen] Found FBReactNativeSpec
Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
Fetching podspec for `boost` from `../node_modules/react-native/third-party-podspecs/boost.podspec`
Fetching podspec for `glog` from `../node_modules/react-native/third-party-podspecs/glog.podspec`
[!] No podspec found for `hermes-engine` in `../node_modules/react-native/sdks/hermes/hermes-engine.podspec`

This only works if I run pod install inside the ios folder.

Tested version: 0.69.0-rc.1

6 replies
@tido64

tido64 May 12, 2022
Collaborator

PR against 0.69-stable: facebook/react-native#33819
PR against main: facebook/react-native#33820 Hector replaced it with a JS script

@cortinico

cortinico May 13, 2022
Maintainer Author

@hramos do we need @tido64 or do we need to cherry-pick some of your commits instead?

@fortmarek

this got merged into 0.69-stable, considering this resolved 👍

This comment has been hidden.

@fortmarek

Hey, thanks for sending these PRs 🙌

I wonder if there is a specific reason why to pick them to the current minor release? While nice improvements, I wonder if they could just wait for the subsequent minor release.

@mikehardy

In fact, I can say that the cluster of Android Studio Chipmunk (release that just came out), and android gradle plugin 7.2.0 is surfacing some incompatibilities (at least 2 I know of, one that will result in a google patch release, one that requires local intervention) https://issuetracker.google.com/issues/232007221 / ankidroid/Anki-Android#11291 - perhaps best to let it settle a bit

removing buildToolsVersion is just best practice though I think?

@cortinico

cortinico May 13, 2022
Maintainer Author

I would refrain from adding them if possible. We're already shipping a lot of changes in 0.69, and bumping AGP during the release process could expose us to several new bugs which will end up delaying the release process even further

Now that facebook/flipper#3117 is finally done and merged, I've decided to test Catalyst compatibility on RN 0.69-rc1 and sum up all the necessary patches.

Let's suppose that user runs npx react-native init and activates Catalyst in Xcode project settings. There will be 3 consecutive errors when trying to build this project and run it locally.

First, Xcode will immediately fail on signing React-Core-AccessibilityResources.

Screen Shot 2022-05-15 at 16 56 24

It may be fixed by adding these lines to Podfile's post_install section:

Screen Shot 2022-05-15 at 17 29 11

Probably it'd be better to add this to react_native_post_install method inside react_native_pods.rb.

Second, build fails due to swift symbols:

Screen Shot 2022-05-15 at 17 08 31

The reason is the absence of bridging header that is suprisingly necessary again (0.68 worked without it). This issue can be solved simply by adding any dummy swift file to Xcode project.

Finally, user faces the most cryptic error about duplicate symbols:

Screen Shot 2022-05-15 at 17 11 41

It is caused by "Dead Code Stripping" in project settings. Although it is Yes by default, it means nothing.

Screen Shot 2022-05-15 at 17 12 41

We need to explicitly add DEAD_CODE_STRIPPING = YES; to app.xcodeproj/project.pbxproj.

Actually, these fixes don't seem drastic, but @kelset probably knows it better.
If it's appropriate time, I can apply these patches to template folder in react-native repo and publish them as a PR.

11 replies
@Arkkeeper

And the fourth issue will appear while trying to build release version or to create an archive in Xcode.

It's described here facebook/react-native#33764 and also requires attention, because it's not about just MacCatalyst builds.

@mikehardy

I haven't seen the release/archive failure you mention @Arkkeeper but I 100% confirm that the first three issues are mandatory things for macCatalyst, and I was waiting for flipper 3117 to finish as well.

I have them programmatically solved like so:

https://github.com/mikehardy/rnfbdemo/blob/360825baab5a2f2e2655caa663559556aaa29f4f/make-demo.sh#L241-L250

@mikehardy

that 4th item, it appears to be new architecture specific? Can you confirm @Arkkeeper ? I'm still testing old architecture, I have enough integration problems at the moment I have not taken the step of doubling my build matrix with new arch 😅

hey. i got this error

Native Component 'RNCSafeAreaView' that calls codegenNativeComponent was not code generated at build time. Please check its definition. 
NativeStackView@http://localhost:8081/src/main.tsx.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=org.reactjs.native.example.StudioGhibliSearchEngineMobile:183974:92
NativeStackNavigator@http://localhost:8081/src/main.tsx.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=org.reactjs.native.example.StudioGhibliSearchEngineMobile:183621:18
EnsureSingleNavigator@http://localhost:8081/src/main.tsx.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=org.reactjs.native.example.StudioGhibliSearchEngineMobile:155447:24
BaseNavigationContainer@http://localhost:8081/src/main.tsx.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=org.reactjs.native.example.StudioGhibliSearchEngineMobile:154953:28
ThemeProvider@http://localhost:8081/src/main.tsx.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=org.reactjs.native.example.StudioGhibliSearchEngineMobile:162847:21
NavigationContainerInner@http://localhost:8081/src/main.tsx.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=org.reactjs.native.example.StudioGhibliSearchEngineMobile:162668:26
ThemeProvider@http://localhost:8081/src/main.tsx.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=org.reactjs.native.example.StudioGhibliSearchEngineMobile:128180:38
RCTView
View
...

when i try to upgrade to 0.69.0-rc.1. is this an error with react-native-safe-area-context? i am already on its latest version.

2 replies
@xiongemi

also. i am using react-native-paper and react-native-vector-icons. i got this error:
simulator_screenshot_A618EB09-01F7-49B9-82ED-22938796082B

i try to link and i got this error when i try to link react-native-vector-icons:

warn Package react-native-vector-icons has been ignored because it contains invalid configuration. Reason: "dependency.assets" is not allowed
error Unrecognized command "link"

is this something with react-native-vector-icons that this library needs to update?

@fortmarek

Hey @xiongemi

We'd need more information to inspect this - ideally, reproducible sample with steps (or at least reproducible steps).

react-native-safe-area-context does support the new architecture (they also have a sample here), so it's most likely tied to your setup.

hramos
May 18, 2022
Maintainer

Here are my pick requests for 0.69:

The purpose of cherry picking these onto 0.69 is two-fold: we want to let the users know that build times will be longer when Hermes is enabled (facebook/react-native@8b8d732), and we want to ensure all available cores are utilized when building Hermes (facebook/react-native@83f4741).

The latter was not an issue for builds on systems that had Ninja installed, because Ninja would automatically use all available cores. The Ninja build system is not part of the RN dependencies that we ask people to install during the quickstart, so if people didn't have it installed, we would instead build Hermes using makefiles and a single core.


There is an additional Hermes build speed improvement that is now in main, and that is where we use the pre-build hermesc on macOS if available (facebook/react-native@644fe43). I hesitate to include that commit in my pick request, because the point of the RC soak process is to achieve stability and perhaps this is a change that is best left for 0.70.

If people do find that landing that change is necessary to improve the user experience in 0.69, then here's the additional list of commits that need to be picked:

Note that only the last commit enables the use of the pre-built hermesc. Cherry picking all the commits ahead of it might not be doable without running into several conflicts, depending on what other changes have landed in main.

19 replies
@tido64

we use the pre-build hermesc on macOS if available

Is the pre-build downloaded from somewhere, or is this just reusing the previous build artifact?

@fortmarek

Is the pre-build downloaded from somewhere, or is this just reusing the previous build artifact?

If I understand it correctly, hermesc should be downloaded along with react-native (see here)

@tido64

Thanks! Pre-builds are essential to not regress the dev experience, imo. Can we try and pick these for 0.69?

This comment has been hidden.

@fortmarek

This has been released in 0.69.0 RC 2, marking as resolved

Hello @cortinico I got this error after upgrading to 0.69.0-rc.2.

[!] No podspec found for hermes-engine in ../node_modules/react-native/sdks/hermes/hermes-engine.podspec

Screen Shot 2022-05-20 at 5 09 10 PM

1 reply
@fortmarek

Hey @ahmadzraiq 👋

We are aware of this (fix is here) and will release a new RC as soon as the PR is merged. Sorry for the issues 🤞

Getting further in my testing, ios debug and ios release and macCatalyst is working, CLI is working with custom iOS script phases, but now I've got a problem on iOS with use_frameworks!

Is this being tested anywhere else, or am I the first to see it? Appears to be a regression where some headers aren't available in a TurboModules object:

❌ /Users/mike/work/Invertase/rnfbdemo/rnfbdemo/node_modules/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleUtils.h:16:10: 'react/bridging/CallbackWrapper.h' file not found
#include <react/bridging/CallbackWrapper.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm not good enough at static frameworks to know why turning it on would cause header pathing issues, but it appears all you need to do to reproduce is:

  • init a new project
  • make sure hermes and flipper are disabled (they do not work under use_frameworks as far as I know, not a regression)
  • add use_frameworks! to your Podfile
  • pod install
  • npx react-native run-ios

Test script branch for rn69, highlighted on static frameworks chunk here: https://github.com/mikehardy/rnfbdemo/blob/f9c0261b38bc347f2ea7e1581c564e504d0bc59a/make-demo.sh#L273-L295

3 replies
@hramos

hramos May 20, 2022
Maintainer

use_frameworks! is not currently supported under the new architecture. Addressing this will require some non-trivial changes. I am not sure if this has been discussed on this repository before, but it is something that we have been tracking (the Meta internal task T47159941 has more details, for any other employees reading this).

@mikehardy

Okay, but, I don't have the new architecture enabled anywhere in my script 🤔 I haven't even started trying to qualify and fuzzbust through new architecture yet, I'm just trying to get to "no regressions from 0.68 to 0.69" 😄 - without enabling new architecture, shouldn't it still work?

I hope so, because the latest release of firebase-ios-sdk says https://firebase.google.com/support/release-notes/ios#cocoapods_users

Breaking change: Podfiles must include use_frameworks! or use_frameworks! :linkage => :static.

@mikehardy

@hramos I see the edits now (I think we must have commented at almost exactly the same time) - if there is any way I could track this (like a branch or something? so I could pull and check, perhaps collaborate) or if there is some other way to help push it along let me know, Firebase is the funding source for my release testing work here so I/we are keenly interested and if I can help I will as it appears this will be a full blocker for us

Don't know if this is a known problem for Win64 but unable to build new architecture on 0.69.RC2 with this particular ninja error which pops up after hermes.vcxproj is built.
Seems to be always looking in the wrong variant folder for hermesc.exe no matter which variant I try
./gradlew :ReactAndroid:hermes-engine:assembleDebug
./gradlew assembleRelease or ./gradlew assembleDebug
I have tried setting an external hermesCommand but that doesnt work either


hermesc.vcxproj -> D:\newarch069rc2\node_modules\react-native\ReactAndroid\hermes-engine\build\hermes\bin\Debug\hermesc.exe

> Task :ReactAndroid:hermes-engine:configureCMakeRelease[arm64-v8a]
C/C++: debug|arm64-v8a :CMake Deprecation Warning at CMakeLists.txt:42 (cmake_policy):
C/C++: debug|arm64-v8a :  The OLD behavior for policy CMP0026 will be removed from a future version
C/C++: debug|arm64-v8a :  of CMake.
C/C++: debug|arm64-v8a :  The cmake-policies(7) manual explains that the OLD behaviors of all
C/C++: debug|arm64-v8a :  policies are deprecated and that a policy should be set to OLD only under
C/C++: debug|arm64-v8a :  specific short-term circumstances.  Projects should be ported to the NEW
C/C++: debug|arm64-v8a :  behavior and not rely on setting a policy to OLD.
C/C++: debug|arm64-v8a :CMake Warning at external/llvh/cmake/modules/GetHostTriple.cmake:18 (message):
C/C++: debug|arm64-v8a :  LLVM_HOST_TRIPLE can't be computed on Windows with this toolchain
C/C++: debug|arm64-v8a :Call Stack (most recent call first):
C/C++: debug|arm64-v8a :  external/llvh/cmake/config-ix.cmake:360 (get_host_triple)
C/C++: debug|arm64-v8a :  external/llvh/CMakeLists.txt:21 (include)

> Task :ReactAndroid:hermes-engine:buildCMakeRelease[arm64-v8a][libhermes] FAILED
C/C++: ninja: error: 'D:/newarch069rc2/node_modules/react-native/ReactAndroid/hermes-engine/build/hermes/bin/Release/hermesc.exe', needed by 'lib/InternalBytecode/InternalBytecode.hbc', missing and no known rule to make it

FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':ReactAndroid:hermes-engine:buildCMakeRelease[arm64-v8a][libhermes]'.
> Build command failed.
  Error while executing process D:\Android\Sdk\cmake\3.18.1\bin\ninja.exe with arguments {-C D:\newarch069rc2\node_modules\react-native\ReactAndroid\hermes-engine\.cxx\Release\2n5x376i\arm64-v8a libhermes}
  ninja: Entering directory `D:\newarch069rc2\node_modules\react-native\ReactAndroid\hermes-engine\.cxx\Release\2n5x376i\arm64-v8a'

  ninja: error: 'D:/newarch069rc2/node_modules/react-native/ReactAndroid/hermes-engine/build/hermes/bin/Release/hermesc.exe', needed by 'lib/InternalBytecode/InternalBytecode.hbc', missing and no known rule to make it
3 replies
@tido64

Which version of Android Gradle Plugin are you using? Can you try 7.2.0? cc @cortinico

@joe-sam

@tido64 I think I'm using AGP 7.1.1. I tried updating the AGP like you suggested, but I think the actual issue may simply be that in the :ReactAndroid:hermes-engine:build.gradle the hardcoded output paths referenced by ninja will have to be made correspondingly variant aware by injecting something like ${variant.buildType.name}

@joe-sam

Was able to manually copy the generated hermesc.exe to the variant folders {Debug, MinSizeRel, Release, RelWithDebInfo} and got the :ReactAndroid:hermes-engine build.gradle working.

hramos
May 26, 2022
Maintainer

Pick request:

If these commits were to be picked onto 0.69.0, we would restore the 0.68 behavior when Hermes is enabled on iOS. These commits rely on pre-built Hermes artifacts that will ship with each React Native release on GitHub, and will be downloaded by CocoaPods when hermes-engine is installed.

The end result is that users should not encounter the long build times during pod install with Hemres enabled that were present in 0.69.0-rc0 through rc3. The time that it will take for CocoaPods to download the pre-built artifacts should be comparable to the 0.68 behavior, where pre-built artifacts were similarly downloaded from GitHub.

For apps that target unpublished versions of React Native (for example, building packages/rn-tester within the RN repo, or apps that target RN main, use nightlies, or commitlies...), there will still be a need to build Hermes locally as there will be no published artifacts in that situation. We plan to continue iterating on the Hermes build integration with Xcode in order to improve the build times in these cases.

Why are we making these changes? With these two commits, the Hermes artifacts are now built on React Native's CI at the same time that a React Native release is cut. In 0.68 and earlier, the Hermes artifacts were built as part of each Hermes release, as a separate process from the React Native release process. By building the Hermes artifacts synchronously with the React Native release, we can now make have Hermes and React Native share the same JSI library.

The switch to using a shared JSI library on iOS has not happened yet. One reason we want to use a shared JSI library is to eliminate a whole category of bugs that may arise from a mismatch between the JSI used by Hermes and the JSI used by React Native. Another reason is that we would no longer have duplicate objects between Hermes and React Native.

0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet