Road to 0.69.0

[cortinico]

2022-06-22 Update

React Native version 0.69.0 has been released (0.69.0-rc.6 has been promoted to stable) 🎉
Conversation about the patch version of 0.69.1 is happening here

---

The branch cut has happened.

Notice

• Current release candidate: 0.69.0-rc.6
• Have an issue with current release candidate? File an issue and we will triage.
• Have a pick request for this release? Does it fall under our pick request qualifications? If so please create a PR against the release branch and comment with the PR link
• If you are release testing. Copy and fill a test checklist.

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.7

Picks for 0.69.0-rc.7

Tracking 0.69.0-rc.6

Picks for 0.69.0-rc.6

• facebook/react-native@e8af5b8
• facebook/react-native@7262acc

Tracking 0.69.0-rc.5

Picks for 0.69.0-rc.5

• facebook/react-native@91452fc
• facebook/react-native@f50936b

Tracking 0.69.0-rc.4

Picks for 0.69.0-rc.4

• facebook/react-native@004b860
• facebook/react-native@38b7065
• facebook/react-native@833222f
• facebook/react-native@eb7cc85
• facebook/react-native@8e80dc8

Tracking 0.69.0-rc.3

Picks for 0.69.0-rc.3

• facebook/react-native@841793a

Tracking 0.69.0-rc.2

Picks for 0.69.0-rc.2

• facebook/react-native@d493f45
• facebook/react-native@494b73c
• facebook/react-native@0605880
• facebook/react-native@94341f0

Hermes:

• Bump Hermes (facebook/hermes@5244f81)

• facebook/react-native@ae28880 - Copy Hermes build scripts to RN to allow RN-specific customization
• facebook/react-native@83f4741 - Remove Ninja build system and ensure make uses all available cores
• facebook/react-native@e49e7c7 - Remove undefined symbol error
• facebook/react-native@ce06214
• facebook/react-native@3412f06
• facebook/react-native@6c2e34b
• facebook/react-native@aaa01f7
• facebook/react-native@d7921f0
• facebook/react-native@12f6081
• facebook/react-native@644fe43 - Use pre-built HermesC if available

Tracking 0.69.0-rc.1

Blocking issues for releasing 0.69.0-rc.1

Picks for 0.69.0-rc.1

• facebook/react-native@b873a4f
• facebook/react-native@1e0226f
• facebook/react-native@93b50be
• facebook/react-native@709a459
• facebook/react-native@6b6adcc
• facebook/react-native@6e2fea8
• facebook/react-native@9328115
• facebook/react-native@09878c8
• facebook/react-native@8b8d732
• facebook/react-native@62ef6f5

[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]

It will support RN 0.68.1 https://blog.expo.dev/expo-sdk-45-beta-is-now-available-88507051f6d2 @wibb36

[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.

[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:

• https://reactnative.dev/contributing/release-testing#test-checklist

[fortmarek]

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

[mikehardy]

With a nice deeplink from @wjaykim this is narrowed down to this line here in react-native-community/cli / cli-config package, it's an incorrect schema validation - I'll follow it up in that repo but it will need a CLI release and dependency bump here to fix if I recall process correctly:

react-native-community/cli@25eec7c#diff-867a86af070dcc54ad750ed04ce12a9eca45b7356e888d140d7ec8219bbe0d4dR72

heads up for incoming PR @grabbou / @thymikee (collaborators on the commit) :-)

(scriptPhases may be a string or an object, not just a string, previously it was joi-validated to object type, now it is string type so anyone using ios script phases that are fully-specified as opposed to just a script path - will fail to build on 0.69.0)

[mikehardy]

Start of a PR here but I couldn't quite make it work, I begged for help on the PR from someone better at CLI to maybe finish 🙏 ? react-native-community/cli#1611

[mikehardy]

PR landed with @thymikee help 🙇 react-native-community/cli@5ac83d8 - I think the next step to resolve this here is a CLI release then a version bump here to ingest it?

[thymikee]

This one landed in v8.0.1. Will apply when lock file is regenerated or for all new projects

[mikehardy]

I just realized I had not confirmed this fix, but this was fixed by Michal - confirmed working for me - and may be considered resolved @fortmarek

[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 ?

[tido64]

PR: facebook/react-native#33830

[fortmarek]

Added to the list of commits to cherry-pick, thanks @tido64 🎉

[kelset]

great report, thanks Simon!

[kelset]

btw folks, did any of you benchmark also the Android side of things? new arch and old arch? (old arch should be unaffected)

[tido64]

0.69.0-rc.3 build times:

Command	Time
pod install (old arch + ninja)	~28 min
react-native run-android (old arch)	~1 min
react-native run-android (new arch)	~16 min

MacBook Pro (16-inch, 2019)
2,4 GHz 8-Core Intel Core i9

[mikehardy]

• MacBook Pro (Retina, 15-inch, Mid 2015) / 2.2 GHz Quad-Core Intel Core i7 (yep, it's old),
• no ninja installed, ccache installed, old arch

I had similar time to Tommy above on first install, scaled for machine speed (~69 minutes).

With ccache installed and configured properly, a second "clean" run (with exception of ccache now "warm"), pod install took 6min 15sec.

So with ccache now perhaps just 3min or so for Tommy's laptop and maybe 1-2mins for a new machine.

The first install hurts with regard to time taken for sure but ccache helps. Now my main preoccupation is disk space. A

After the build, 17GB is occupied on disk in node_modules/react-native, almost all hermes
My ccache occupies quite a bit of extra space (7.15GB! checked by clearing/zero-ing it then rebuilding), which will count against the 10GB available in github workflows. I would assume most people are saving android AVD snapshots and gradle caches for Android build acceleration as well. Just AVD snaps and gradle cache for a react-native app is maybe 6-7GB so this will no longer fit in github's open source cache. iOS ccache used to be just around 1.5GB.

Not sure if there are any derived artifacts from the compilation that are intermediates that may be cleared after the compile of final artifacts, but those seem to be the biggest space hogs

[cortinico]

Hey all,
Just a heads up on behalf of Meta as I realized we haven't provided an official response in this thread yet. We obviously deeply care about the DevX, and we don't want to introduce any regressions, with a specific focus on users which are on the Old Architecture. We want to make sure the DevX for them remains consistent and we don't introduce significant build impact, like the one reported here.

We spent significant time on this issue, as the Hermes build for iOS was impacting users on both New and Old Architecture and 0.69.0-RC6 should address this. We will essentially re-use the same mechanism we were using on 0.68 on iOS while still providing a bundled version of Hermes.

I'm sorry this took a little bit longer than expected (and more RCs than we hoped to), but I personally believe 0.69 was unshippable as it was before RC6 and I'm glad we took the time to address this.

I'm resolving this specific thread as this was addressed, but feel free to open another if you're noticing other issues.

[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 :)

[fortmarek]

I raised a PR for this here.

[cortinico]

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.

[fortmarek]

Hey @xiongemi

The error you are seeing is most likely because support for iOS 11.0 was dropped and React Native currently supports only versions >= 12.4 (see the change here). You will need to bump your deployment target.

[xiongemi]

does that mean I have to manually change the IPHONEOS_DEPLOYMENT_TARGET? is there a way to do it automatically? every time i do a pod install, it changes ios/Pods/Pods.xcodeproj/project.pbxproj to IPHONEOS_DEPLOYMENT_TARGET to 11.

[mikehardy]

I believe you need to change it in your Podfile, and your xcode project's info section, then they will line up correctly?

[fortmarek]

As Mike said, you should update the value in your Podfile as it drives what gets written to the IPHONEOS_DEPLOYMENT_TARGET env variable.

[fortmarek]

Let me know @xiongemi if you are still running into any issues, until then we'll consider this resolved.

[cortinico]

Sharing this from the React Native issue tracker:

• Invariant Violation: ViewPropTypes has been removed from React Native. facebook/react-native#33734

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

[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 🙂

[fortmarek]

Added to the list of picks cc @cortinico 🚀

[chrayel]

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.

[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'

4. npm install mkdirp
5. npx react-native start
6. npx react-native run-android

• Builds successfully

7. npm uninstall mkdirp

• Builds successfully

[mganandraj]

(I believe it is always available on Windows, but I may be wrong)

@neildhar ICU is available on all Windows 10 machines with May 2019 Update. It won't be available on Windows 7, Windows 2016 server, or a unpatched Windows 10, which are rare these days. I think we could assume ICU to be available and make sure that the requirement of having a properly patched Windows10+ OS properly documented.

[lindboe]

I'm also having the mkdirp issue on 0.69.0-rc1, didn't see it on 0.69.0-rc0

[mikehardy]

mkdirp has a cherry pick request below, it's already fixed on main (discovered it today myself)

[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

[brunoducattii]

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...

[cortinico]

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 👍

[brunoducattii]

@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.

[fortmarek]

Hey @joaotmachado 👋

First off, sorry for the longer response time.

Could you create a reproducible project that we could use to replicate the issue? And ideally try it with and without the third-party libraries that you are having issues with? It might be that this will need attention from the maintainers and won't be possible to fix in react-native directly.

[brunoducattii]

FYI: Several Libs from React Native needed to manually remove folly_json and folly_futures to work with RN 0.69. Until today React Native Screens and React Native Gesture Handler need it.

software-mansion/react-native-gesture-handler#2051

[fortmarek]

Hey @joaotmachado!

Both React Native Screens and React Native Gesture Handler are aware of this. The change will make the libraries incompatible with 0.68, so the relevant PRs can only be merged once 0.69 is properly released. Thanks for the heads-up!

[kelset]

quick update here so that we don't lose track of the links: there's now a PR on the Hermes side to address this: facebook/hermes#749

the problem is that this will land in main of hermes, so how we'll get the 0.69 branch to consume this new version of Hermes with the fix needs to be determined. (is a new git tag on hermes main + bump of dep on RN side enough?)
cc @neildhar @cortinico @fortmarek

[fortmarek]

We'll need to repeat the Hermes-related steps mentioned here and then it should be fine 👍

[kelset]

ok so we need to get the new hermes tag, do ./scripts/bump-hermes-version.js with it and pray that nothing breaks 🤣

[cortinico]

Exactly 👍

[fortmarek]

Marking as resolved as it's already chosen to be picked, we can reopen this thread if it's still an issue in the next RC.

[xiongemi]

question: how do you setup jest with react-native 0.69? it works fine with 0.68.2. i got an error when i try to run jest unit test:

    SyntaxError: /Users/emilyxiong/Code/tmp/studio-ghibli-search-engine/node_modules/@react-native/polyfills/error-guard.js: Missing semicolon. (14:4)

      12 | let _inGuard = 0;
      13 |
    > 14 | type ErrorHandler = (error: mixed, isFatal: boolean) => void;
         |     ^
      15 | type Fn<Args, Return> = (...Args) => Return;
      16 |
      17 | /**

i do have @react-native in the transformIgnorePatterns.

this is my jest.config.js:

module.exports = {
  displayName: 'studio-ghibli-search-engine-mobile',
  preset: 'react-native',
  testRunner: 'jest-jasmine2',
  resolver: '@nrwl/jest/plugins/resolver',
  moduleFileExtensions: ['ts', 'js', 'html', 'tsx', 'jsx'],
  setupFilesAfterEnv: ['<rootDir>/test-setup.ts'],
  transformIgnorePatterns: [
    'node_modules/(?!((jest-)?react-native|@react-native(-community)?)|expo(nent)?|@expo(nent)?/.*|@expo-google-fonts/.*|react-navigation|@react-navigation/.*|@unimodules/.*|unimodules|sentry-expo|native-base)',
  ],
  moduleNameMapper: {
    '.svg': '@nrwl/react-native/plugins/jest/svg-mock',
  },
  transform: {
    '^.+\\.(bmp|gif|jpg|jpeg|mp4|png|psd|svg|webp)$': require.resolve(
      'react-native/jest/assetFileTransformer.js'
    ),
  },
  testEnvironment: 'node',
};

[fortmarek]

Hey @xiongemi 👋

Could you provide a sample project, ideally one created from the RN template from the current RC (npx react-native init RN069RC6 --version 0.69.0-rc.6)? Then we could look into it.

That being said, this does not look like a completely new issue and is most likely related to a possible misconfiguration of babel.config.js or jest.config.js, you can get some hints from the discussion here

[efstathiosntonas]

it seems that this issue does not only apply for Hermes, Bugsnug throws the same error, 'Bugsnag/Bugsnag.h' file not found, this is their podspec. Have no clue if these are related, just posting it here.

edit: tried everything before posting this comment, remove node_modules and yarn.lock, delete podfile.lock, deintegrate pods, delete pods dir, delete pods cache under /Library, cleaned derived cache and reinstalled everything.

edit2: during pod install there's no Installing BugsnagReactNative (x.x.x)

edit3: After adding pod 'Bugsnag' on Podfile the build succeeded 🤔