Road to 0.71.0

[kelset]

The branch cut has happened.

Notice

• Current release candidate: 0.71.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.
• Are you testing nightlies? Please report in the dedicated discussion here: 🌜 Nightlies feedback #49

Highlighted Changes

Community-coordinated efforts

• React Native now support flex-gap feat: flex gap bindings facebook/react-native#34974 (Credits @intergalacticspacehighway and @jacobp100, coordinated by @NickGerleman)
  • documentation: feat: flex gap docs (0.71.0 release) facebook/react-native-website#3398
• improvements to codegen, thanks to everyone who contributed to the ☂️ task ☂️ Improving Codegen facebook/react-native#34872 coordinated by @cipolleschi
  • Codegen supporting split platforms configs
• coordinated by @necolas, in [w3c] ☂️ Web Props (Part 1) umbrella issue facebook/react-native#34424 and [w3c] ☂️ Web Styles (Part 1) umbrella issue facebook/react-native#34425 (RFC: RFC: React DOM for Native (reduce API fragmentation) react-native-community/discussions-and-proposals#496), a big number of improvements to React DOM / Web props support on React Native:
  • Improved compatibility with React DOM. Support for 29 new web props and a dozen CSS fixes.
  • Includes ARIA props; Image src and srcSet; TextInput enterKeyHint and inputMode; and better CSS Colors support.
  • Thanks to @gabrieldonadel @dakshbhardwaj @dhruvtailor7 @ankit-tailor @madhav23bansal.
  • documentation: feat: Add aria Web props to component docs facebook/react-native-website#3404, feat: Update documentation regarding W3C Web Styles  facebook/react-native-website#3403

User-facing improvements

• typescript types bundled in the node_module (need to write about how to migrate from DT ones)
• better error messaging / ViewPropTypes ( facebook/react-native@af0e6cd )
  • explainer: facebook/react-native@b966d29
• bump to Jest 29.2
• bump CLI to v10 and Metro to 0.73.3
  • Metro specific changes:
    • Terser as the default minifier
    • We no longer transpile the ** operator --> BigInt is now fully supported for the first time (support in Hermes shipped in RN 70 but was missing this Metro fix)
    • Improved file watching on Apple silicon
• AsyncStorage fully removed. facebook/react-native@20eeb1b
• Hermes bumped
  • read here the main highlights

Under the hood improvements

• better artifacts management and migrating to Maven Central for prefabs to improve build times (both iOS and Android) for Hermes and new-arch
• refactoring of JSI in cocoapods (see facebook/react-native@6b129d8)
  • tl;dr: React-jsi will be split into React-jsc and React-jsi in 0.71. React-jsi now solely provides jsi - if you use JSCRuntime, you will need to add React-jsc as a dependency.
• bump & aligned to NDK23 (patch with M1 support), so no more NDK21/NDK24 tricks
• bump of React Native Gradle Plugin and update the template to use the newest API.
• template has a smaller new-arch footprint
• template will now use Typescript: Use TypeScript by default for new applications facebook/react-native#35165
• cleaned up the android side build.gradle interface for react config, see https://github.com/facebook/react-native/pull/35108/files#diff-814e447d5146c22373edf18d5a30c348725747984640e2311cccc7d362a93664R10
  • TODO: @cortinico document this properly
• Sets the namespace via Gradle and not via AndroidManifest Sets the namespace via Gradle and not via AndroidManifest facebook/react-native#35094
• improvements to the E2E and overall testing process in core

Release Process

Checklist

• Changelog PR
• Draft Blog Post
• Follow up on release dependencies

  When ready to publish stable

• Ship changelog [Chore] Changelog for 0.71.0 facebook/react-native#35200
• Ship blog post
• Make PR to react-native-website with the new version cut (see docs)

Retrospective Topics

Click to show/hide

• facebook/react-native@e4b5d3e && facebook/react-native@4f3ca8f
  • wrong argument getting passed
  • wrong version in dry run
• Alignment between nightlies and release flow. Currently the nightlies and the release flow are very different because:
  • nightlies run on main; releases run on a branch
  • nightlies use version 1000; releases run with a specific version number
  • nigthlies do not use tags; releases do
  • We use these three information to define the flow of execution of the CI and therefore the two exec are different.
• Proposal: We should sit down and rethink the CI pipelines/releases steps:
  • All the steps should be independent from the scenario.
  • We shouldn't leak information we use in the various steps in folders and artifacts (for example, tarballs with the version name)
  • We should have "declarative" scenarios where we combine the independent steps.
• the Maven Central incident ([FIXED] Android build failures No matching variant of com.facebook.react:react-native:0.71.0-rc.0 was found. facebook/react-native#35210)
• content generation (changelog, blogpost, etc)

Release Status

Tracking 0.71.0 (-rc.7 or 0.71.1)

Blocking issues for releasing 0.71.0

Picks for 0.71.0-rc.7 (or 0.71.1)

• facebook/react-native@64475ae
• facebook/react-native@5eb25d2
• Exclude react-native-flipper when NO_FLIPPER=1 to prevent iOS build fail facebook/react-native#35686
• [LOCAL] fix(cli,metro,babel): bump cli and metro and babel to fix Windows+Metro issue facebook/react-native#35786
• facebook/react-native@e948c79

Tracking 0.71.0-rc.6 (released ✅)

Tracking 0.71.0 (-rc.6 or 0.71.1)

Blocking issues for releasing 0.71.0

• CI is failing due to an error 403 we are getting from Sonatype when we want to create the NPM package. It is probably an internal permission problem, Nico is investigating it as it is release-blocking. See ticket: https://issues.sonatype.org/browse/OSSRH-87563
• CircleCI secret security incident forced a full rotation of all the secrets

Picks for 0.71.0-rc.6 (or 0.71.1)

• facebook/react-native@64475ae
• fix(CI): prevent the e2e test from running on 0.71 facebook/react-native#35681
• facebook/react-native@5eb25d2
• Exclude react-native-flipper when NO_FLIPPER=1 to prevent iOS build fail facebook/react-native#35686
• [LOCAL] fix(cli,metro,babel): bump cli and metro and babel to fix Windows+Metro issue facebook/react-native#35786

Tracking 0.71.0-rc.5 (released ✅)

Blocking issues for releasing 0.71.0-rc.5

• guidance for library maintainers (Android especially) comment #1, comment #2, comment #3, comment #4
  • should be handled, just adding a note to verify all cases and ensure proper documentation gets added

🔴 hard blockers:

• [0.71] Release of React Native 0.71 is currently blocked by an AGP stable release facebook/react-native#35592
  • we have a workaround, TBD: De-bump AGP to 7.3.1 and do not use addGeneratedSourceDirectory facebook/react-native#35631
• we need to fix the eslint config, see here
  • a local commit fix will be enough, in main is not needed

Picks for 0.71.0-rc.5

• facebook/react-native@1b7127b
• (non mandatory) fix(CI): prevent the e2e test from running on 0.XX-stable branches facebook/react-native#35667
  • might get superseded by fix(CI): prevent the e2e test from running on 0.71 facebook/react-native#35681
• facebook/react-native@d867ec0
• facebook/react-native@c7e1e00 (try to) (will need codegen release)
• facebook/react-native@ef11e15
• facebook/react-native@e71b094
• Android Picks
  • facebook/react-native@46ffeca
  • facebook/react-native@52f4ff7
  • facebook/react-native@3487640
  • facebook/react-native@51a48d2
• typescript picks
  1. facebook/react-native@25a25ea
  2. facebook/react-native@454f9dc
  3. facebook/react-native@1752fdc
  4. facebook/react-native@e1af630
  5. facebook/react-native@2c2cb09
  6. facebook/react-native@0d09131
  7. facebook/react-native@b15be0e
  8. facebook/react-native@0793128
  9. facebook/react-native@4e5421f
  10. facebook/react-native@8d6e2f8
  11. facebook/react-native@621969b
  12. facebook/react-native@c4862a2
  13. facebook/react-native@76a1445

Tracking 0.71.0-rc.4 (released ✅)

Blocking issues for releasing 0.71.0-rc.4

• Static images are not rendered on Android for 0.71.0-rc.0 facebook/react-native#35439
• doesn't work on windows: Build failed with an exception rn@0.71.0-rc.2 facebook/react-native#35472
• @typescript-eslint/eslint-plugin and @typescript-eslint/parser to devDependencies (link to comment)
• compile error 'memory' file not found when building for iOS (link to comment)
• unclear CMake error (link to comment)
  • should have a fix
• issue with nightlies (link to comment)
  • caused by Codegen cleanup step added in the cocoa pod script does not work properly - non blocker
• deprecated proptypes still failing in some scenarios (link to comment)
  • non blocker, hermes-parser related, tasked to hermes team // commit landed, in cherry pick section
• issue when detaching Metro: Cannot read property 'code' of undefined facebook/react-native#35514
  • non blocker, tasked internally // commit landed, in cherry pick section // should be handled by Metro bump itself

🔴 hard blockers:

• hermes name in iOS build is "behind", need to fix caching [0.71] Hermes version is rc.2 when it should be rc.3 on iOS facebook/react-native#35537
  • should be fixed by: facebook/react-native@0edcbc3
• issue with hermes building from source on certain CIs Hermes is built from source on the CI for iOS in React Native 0.71.0-rc.3 facebook/react-native#35547
  • should be fixed by: facebook/react-native@ed16fdb
• [0.71] Release of React Native 0.71 is currently blocked by an AGP stable release facebook/react-native#35592

Local commits to backport to main

1. facebook/react-native@0edcbc3
   • Commit: facebook/react-native@65e0f79
2. facebook/react-native@c6fa633
   • PR: Properly support both libraries and use_frameworks (#35624) facebook/react-native#35637

Picks for 0.71.0-rc.4

• facebook/react-native@4df793f
• facebook/react-native@68d6214
• facebook/react-native@e1bca8f
• facebook/react-native@da4243b
• facebook/react-native@3e91415
• facebook/react-native@913ebd2 (requires RNGP bump)
• facebook/react-native@9c75871 (we might not need to pick this one, Metro bump could be enough)
• facebook/react-native@5928144
• facebook/react-native@28147f8
• facebook/react-native@822396d
• facebook/react-native@c6fa633

Tracking 0.71.0-rc.3 (released ✅)

Blocking issues for releasing 0.71.0-rc.3

• provide a migration path for libraries that rely on node_modules/react-native/android folder (comment #1, comment #2, comment #3)
• Static images are not rendered on Android for 0.71.0-rc.0 facebook/react-native#35439
• doesn't work on windows: Build failed with an exception rn@0.71.0-rc.2 facebook/react-native#35472
• regression in use_frameworks: Road to 0.71.0 #41 (comment)
• compile error 'memory' file not found when building for iOS (link to comment)
• @typescript-eslint/eslint-plugin and @typescript-eslint/parser to devDependencies (link to comment)
• unclear CMake error (link to comment)
• issue with nightlies (link to comment)

Local commits to backport to main

• facebook/react-native@05646f8 & facebook/react-native@ceaebc6
  • fix(dependencies): move mockfs to the right package.json facebook/react-native#35476
• facebook/react-native@67c373f & facebook/react-native@e809e4b & facebook/react-native@6107793
  • fix(e2e script): backport from 71 fixes to the E2E script facebook/react-native#35477
• facebook/react-native@ba1a9de
  • Backport PR: Bypass tag check in dry run (#35428) facebook/react-native#35470
• facebook/react-native@fc1dbb8
  • Backport PR: facebook/react-native@0d3d002
• facebook/react-native@9979e38
  • fix(e2e script): backport from 71 fixes to the E2E script facebook/react-native#35477
• facebook/react-native@49c0267
  • Backport PR: Use the right logic to decide when we build Hermes from source facebook/react-native#35469

Picks for 0.71.0-rc.3

• Bump Hermes and RNGP
• facebook/react-native@319631f
• All the necessary Android picks are listed here in order:
  • [0.71] Android Pick Requests for 0.71.0-rc3 facebook/react-native#35510
• Regression Fix for use_frameworks! on the Old Arch
  • facebook/react-native@dd0bf83
  • facebook/react-native@c5de1eb
  • facebook/react-native@3d7b53d
  • facebook/react-native@4e8526c
• facebook/react-native@4a4ccee
• facebook/react-native@0376aa4
• facebook/react-native@f5e5274

Tracking 0.71.0-rc.2 (released ✅)

Blocking issues for releasing 0.71.0-rc.2

• ⚠️ building iOS breaks in all scenarios (Hermes/JSC - old arch/new arch) ⚠️

Workaround for building iOS in RC1

While we address the problem with iOS, you can get a successful iOS build by opening your Xcode project (RN0710RC1.xcworkspace), navigating to RN0710RC1's Build Phases, and removing the last phase [RN]Copy Hermes Framework by clicking on the bin icon and confirming.
Note that you will have to re-remove this build phase if you run pod install again.

Picks for 0.71.0-rc.2

Tracking 0.71.0-rc.1 (released ✅)

Testing RC0's Android side

After the outage on the 4th of November, we managed to have the artifacts removed from Maven Central.
To build v0.71.0-RC0 on Android successfully, you will need to do the following:

1. Create a new app using the command: npx react-native init <YourAppName> --version 0.71.0-rc.0
2. Manually download the maven-local.zip archive (you can also find the link in this release).
3. Unzip the maven-local.zip on a folder on your disk.
4. Add the REACT_NATIVE_MAVEN_LOCAL_REPO=<path_to_the_maven-local_unzipped_folder> setting to the android/gradle.properties file
5. To run Android, use the usual command: yarn android
6. (To run iOS, use the usual command: yarn ios)

Local commits to backport to main

1. facebook/react-native@becb47c
   • backport PR: Fix avoid forcing podspec versions facebook/react-native#35274
2. facebook/react-native@41bf725
   • To backport this properly, we will need more than one PR:
     1. Remove version from the tarball facebook/react-native#35285
3. facebook/react-native@741d102
   • backport PR: deps(cli): "backport" CLI bump into main from 0.71 facebook/react-native#35260
4. facebook/react-native@fd5e282 superseeded by facebook/react-native@b8f8ac0 supersseded by facebook/react-native@5c9f160 superseeded by facebook/react-native@41a80f2
   • backport PR: fix: Change checkout cache strategy facebook/react-native#35259
5. facebook/react-native@0f72abf superseeded by facebook/react-native@32931b1
   • backport PR: fix(release scripts): backport fixes for CI from 0.71 into main facebook/react-native#35258
6. facebook/react-native@8e3b620
   • backport PR: fix(release scripts): backport fixes for CI from 0.71 into main facebook/react-native#35258
7. facebook/react-native@e4f23f4
   • backport PR: Invoke closeAndReleaseSonatypeStagingRepository in the publish gradle invocation facebook/react-native#35272

Blocking issues for releasing 0.71.0-rc.1

• Hermes on iOS build issues (comment #1, comment #2)
• Maven Central for Android, need to void com.facebook.react:react-native: and migrate to something like com.facebook.react:react-native-android or similar

Picks for 0.71.0-rc.1

(from older to newest)

• facebook/react-native@35b2150
• facebook/react-native@7203187
• facebook/react-native@9cb0261
• facebook/react-native@ddba780
• facebook/react-native@394486e
• facebook/react-native@d07575b
• facebook/react-native@c0a06d2
• facebook/react-native@9fed9cd
• facebook/react-native@4c1d5ad
• facebook/react-native@e36c492
• facebook/react-native@11c8bf3
• facebook/react-native@1aa157b
• facebook/react-native@da27c78
• facebook/react-native@418e957
• facebook/react-native@1565634
• facebook/react-native@55b1670
• facebook/react-native@81e441a
• facebook/react-native@27e7295
• facebook/react-native@25132c8
• facebook/react-native@cb7f1b1
• facebook/react-native@5dd0f73
• facebook/react-native@850f855
• facebook/react-native@f12b12c

[kelset]

nvm looks like it's a proper issue: #41 (comment)

[NickGerleman]

Didn't follow the links and made a duplicate of this thread in #41 (comment) accidentally 🙂.

But we should absolutely be highlighting these. It's going to be one of the bigger day-to-day changes for developers using RN to come out of the release.

I've been seeing more documentation for these being added to the site. We can probably give a summary of the overall change (e.g. mention colors, aria, affected components), then cross-link to the more detailed documentation for the added props.

[kelset]

@NickGerleman 100%, documentation is king for this type of changes.

[kelset]

still, can you folks come up with a quick list of highlights that I can copy/paste above?

[necolas]

Something like...

• Improved compatibility with React DOM. Support for 29 new web props and a dozen CSS fixes.
• Includes ARIA props; Image src and srcSet; TextInput enterKeyHint and inputMode; and better CSS Colors support.
• Thanks to @gabrieldonadel @dakshbhardwaj @dhruvtailor7 @ankit-tailor @madhav23bansal.

[kelset]

thanks @necolas - I've updated the highlights section, lmk what you think of that for now; I've tried to shape it up a bit as a "skeleton" that we can use to prepare the blogpost down the road

[mikehardy]

That was a good one, wasn't it! Thanks for posting this here - it was where I saw it first anyway. I believe we have a valid workaround now at the linked issue.

The relationship to the release process is that this RC was somehow published to maven central, whereas that had not happened since the 0.20 version, and it caused android build failures.

[cortinico]

Thanks for mentioning it. The fix and the explanation to what happened is here:

• [FIXED] Android build failures No matching variant of com.facebook.react:react-native:0.71.0-rc.0 was found. facebook/react-native#35210

[jacobp100]

You should still take some credit - without you, it wouldn't be in this release

[intergalacticspacehighway]

^agreed! 😅

[cortinico]

Are we planning to publish new versions on mavenCentral from now on?

Yes. More context on this here react-native-community/discussions-and-proposals#508

As it might cause issue for android builds since most of the react native libs use transitive dependencies.

Can you clarify what's your concern?

[ricku44]

Most RN libs have transitive RN dependency with '+' symbol. That means it will point to latest version of RN. Since mavenCentral is added as repo source by default in Android, latest version turns out to be 0.71.0 instead of stable version from node modules (say 0.70.5).
So the build is failing due to mismatches since RN libs are installed as per node module RN version but gradle is considering 0.71.0 RN. Even Hermes dependency getting dropped in the process.
As a workaround, we had to force gradle to use a particular version instead of this.
Let me know, if any clarification needed.

[kelset]

As a workaround, we had to force gradle to use a particular version instead of this.

My 2C$, this shouldn't be considered a workaround but it's how it should be done. Setting a dependency on android side as :+ is troublesome and we've experienced this first hand during this past weekend.

[cortinico]

As a workaround, we had to force gradle to use a particular version instead of this.

Thanks for clarifying @ricku44
That's not a concern as we're now relying on React Native Gradle Plugin which will handle dependency resolutions for us.

First, we won't be publishing to com.facebook.react:react-native anymore to prevent dependency clash as the ones happened with 0.71.0-rc0. We picked a new set of coordinates com.facebook.react:react-android. The Gradle Plugin in 0.71 has a substitution rule that "redirects" all the usages of com.facebook.react:react-native to com.facebook.react:react-android

Second, as for the dependency with the "+" in all the libraries. The Gradle Pluign will take care of that as well, forcing the specific version of React Native. We also removed the "+" from the Template, and in the future libraries will have to do the same (e.g. depend on implementation('com.facebook.react:react-android') without the +).
We'll publish guidance for libraries in the near future.

[cortinico]

Resolving as this is essentially answered. The logic for handling 3rd party libs as well will be shipped inside RC3: facebook/react-native#35510

[filipengberg]

When trying to upgrade to 0.71.0.rc-0 in my project to test it there is no node_modules/react-native/android folder with prebuilt
binaries. This makes the build fail since some third party libraries depend on it (react-native-mmkv and react-native-reanimated in my case). Is this something that has changed for 0.71 or is it always missing for RC-builds? Or maybe its something wrong with setup?

Sorry if this is off topic, feel free to close it if thats the case!

[filipengberg]

By the way seems like the work is already started by @tomekzaw to make reanimated support 0.71: software-mansion/react-native-reanimated#3745 Thats awesome! ❤️

[tomekzaw]

Thanks for the ping. We are aware of all the recently introduced breaking changes. From the perspective of react-native-reanimated, the following things need to be re-implemented (see PR description):

• Add support for React Native 0.71 software-mansion/react-native-reanimated#3745

Too bad 0.71 doesn't support AARs & prefabs simultaneously so library authors could migrate incrementally. Will keep you updated.

[cortinico]

using prefabs instead of unpacking shared libs from AARs (this may take a while)

We should pair on this, but in general this should allow you to clean-up a lot of unnecessary build logic from reanimated (you won't need to download glob, folly, etc. anymore).

detecting if Hermes is enabled (previously this was available in project.ext.react.enableHermes)

I've left a comment on your PR

other changes in app template build.gradle
some C++ changes in UIManagerBinding and facebook::hermes::inspector::chrome::disableDebugging
using TypeScript types in example apps

Let me know if you have specific questions. Happy to support.

Too bad 0.71 doesn't support AARs & prefabs simultaneously so library authors could migrate incrementally. Will keep you updated.

I've tought about it (i.e. publishing both on Maven Central & inside the /android folder). The problem is that the package inside the /android folder can't be prefab-compatible due to size limitation of NPM. So we'll have to move it one way or another. We could publish inside ./android a non-prefab enable .aar but I'm afraid it will create more confusion than benefit (problems like duplicated classes or so).

[tomekzaw]

We should pair on this, but in general this should allow you to clean-up a lot of unnecessary build logic from reanimated (you won't need to download glob, folly, etc. anymore).

Yeah, the thing is that we still need to support older versions of RN and honestly it became unmaintainable a long time ago. So we can either add some conditionals again or have two different build.gradles, one for <=0.70 and one for 0.71+.

I've left a comment on your PR
Let me know if you have specific questions. Happy to support.

Thanks, gonna try out the Hermes snippet soon. For now I'll hard-code it and try to deal with updating app templates & adding prefab support.

I'm afraid it will create more confusion than benefit (problems like duplicated classes or so).

Sounds reasonable. I'm considering manually packing .so files from .apk into .aar so I can link shared libraries in CMake "the old way" and have some kind of checkpoint before adding prefab support.

[WoLewicki]

Yeah, blank project works correctly.
Ok so I changed this line so that it takes implementation 'com.facebook.react:react-native:+' on both new and old arch, and now it fails on this line.
This is the generated Android-rncli.cmake:

# This code was generated by [React Native CLI](https://www.npmjs.com/package/@react-native-community/cli)

cmake_minimum_required(VERSION 3.13)
set(CMAKE_VERBOSE_MAKEFILE on)

add_subdirectory(/Users/wojciechlewicki/work/react-native-svg/FabricExample/node_modules/react-native-svg/android/src/main/jni/ rnsvg_autolinked_build)

set(AUTOLINKED_LIBRARIES 
  react_codegen_rnsvg
)

so it points to our CMakeLists.txt. Based on the error message:

it fails on line 31: https://github.com/software-mansion/react-native-svg/blob/1a2e8c74ed3da06d83e8c386170fa28ad96c4697/android/src/main/jni/CMakeLists.txt#L31. This may be the result of react-native-svg and react-native-screens having custom autolinking configuration due to having custom cpp state (more info and PR from RNScreens here). Is it possible to somehow link this custom state from JS in 0.71? It would probably solve the issue and simplify our configs.

[WoLewicki]

Based on suggestion from @j-piasecki I changed https://github.com/facebook/react-native/blob/dac6806559c49b267ce6eb2722c9ff3b9108ead1/ReactAndroid/cmake-utils/ReactNative-application.cmake#L109 to target_link_libraries(${autolinked_library} common_flags) and now the build fails on #include <react/renderer/components/image/conversions.h> in generated Props.cpp with such error: fatal error: 'react/renderer/components/image/conversions.h' file not found.

[WoLewicki]

After debugging the problem with @kkafar we managed to run the app by linking rrc_image in cmake: software-mansion/react-native-svg@142070f (#1911) so its headers are visible in Props.cpp. The name was taken from here: https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/ReactCommon/react/renderer/components/image/Android.mk#L10

[cortinico]

@WoLewicki can this be cosnidered solved?

[WoLewicki]

Yes, I believe so.

[Titozzz]

Weird, because this commit facebook/react-native@936d69e is inside the RC

[cipolleschi]

Yes the commit has been picked. But I fear we published a tarball pre-commit (so, built in Debug mode) because of CircleCi cache.

Basically, to have a faster ci, we are caching the tarballs that are created from every commit. In the release build, we asked to build Hermes from main, but we already built it once from that commit, before the picked fix. The CI restored that tarball and we skipped the Hermes build, actually publishing the Debug version. 🤦‍♂️

I'll be working on porting the local fixes to main tomorrow and I'll make sure that for RC1, we will have the right tarball!

[kelset]

@cipolleschi we'll basically have to invalidate the cache similar to what we did with the git one to address this in the branch, right?

[cipolleschi]

Yes, worse case scenario, that would trigger a rebuild.
But I'd rather spend some time to find a better solution that can automatically understand when the details of the Hermes build changed.

[cipolleschi]

Hermes Features for 0.71.0

React Native 0.70 was a huge milestone for the community: Hermes became the default engine for RN. Since then we have hit the ground running with DevX improvements, performance improvements, and new language features. Here is a quick overview of some of those changes we’ve made since Hermes became the default.

• 7208d Fix how BigInt and Symbol are transported over Chrome DevTools Protocol.
  • Previously, BigInts and Symbols would always appear as undefined in the console. With this diff, they correctly show up everywhere in the debugger- this was a good DevX improvement.
• db19b Implement loading source maps over the network in Metro
  • Restores the ability to use source maps in recent versions of Chrome Dev Tools outside Flipper.
• b7164 Implement debugger support for global name requests
  • Gives debuggers knowledge of global variables (e.g. when offering auto-completion when typing in the console)
• 2b439 Implement debugger script compiling
  • Allows debuggers to compile scripts during a debug session (e.g. to provide correctness feedback as code is typed in the console)
• 1900b Implement basic JSON.parse optimization.
  • Some users make heavy use of JSON.parse, specifically when using libraries such as Redux. This change brought roughly a 30% perf improvement.
• a2647 Make Date parsing more fault tolerant, matching behavior of JSC/V8.
  • This was blocking a user from using a version of Expo.
• ebe29 Support .at() method for String, TypedArray, and Array.
  • This was a language feature asked on GH. We are always working towards making Hermes more spec-compliant.

[NickGerleman]

Feedback Wanted: TypeScript

Looking for general feedback from anyone who has tried the new TypeScript flows in 0.71. E.g. your experience:

1. Building a new app TypeScript app via 'react-native init'
2. Using 0.71 in your existing TypeScript app without using '@types/react-native'

[NickGerleman]

An explicit devDependency would be needed for correct resolution when specifying parser/plug-in in the apps ESLint config, like the template did previously. Though looking at the community ESLint config it already is specifying the parser/plug-in for TS files so I don’t know why it was re-specifying it in the first place. Can probably be removed.

[NickGerleman]

Okay I checked the history. react-native-community/react-native-template-typescript#240 added these to fix another change to alter options of the community config. The underlying issues were later fixed in the community ESLint config, and really should never have been in the template. I removed the config overrides already because I saw they were fixed, so we should also be able to remove the explicit dependencies now too I think.

[kelset]

@radko93 confirmed that we should be able to remove them without troubles 👍 I can take care of the PR if you're busy, should be up in a couple hrs

[kelset]

up: facebook/react-native#35527

[NickGerleman]

facebook/react-native@68d6214

[cortinico]

Not necessarily, but it would be good to include.
@makovkastar worked on it for adding SDK 33 support in the next stable release of RN. If we don't pick it now, users will have to wait for the next stable release for SDK 33 support.

[tomekzaw]

In react-native-reanimated we still need to use manually link these shared libraries "the old way" on Android with new architecture enabled:

• react_render_scheduler
• react_render_uimanager
• react_render_mounting

Without them, the linker yields the following errors, respectively:

• error: undefined symbol: facebook::react::Scheduler::getUIManager() const
• error: undefined symbol: facebook::react::UIManager::getShadowTreeRegistry() const
• error: undefined symbol: facebook::react::ShadowTree::commit(std::__ndk1::function<std::__ndk1::shared_ptr<facebook::react::RootShadowNode> (facebook::react::RootShadowNode const&)> const&, facebook::react::ShadowTree::CommitOptions const&) const

Would it be possible to prefabricate these shared libraries as well for ease of use and consistency?

[cortinico]

Thanks for the thorough description @tomekzaw.
Just to give you a small bit of context, the current set of libraries that we decided to prefab-ify, was mostly guidaded by the new app template. I essentally migrated library one by one, till the new app template was effectively running only on prefabbed libraries. If a library was left out, it's mostly because the sample app is not linking against it. Nothing prevents us from prefabbing it as well.

Here what I believe are the actionables for me, just wanted to cross check for you if this makes sense:

1. Missing symbols
   Question: Why does react-native-0.71.0-rc.0-debug.aar contain libreact_render_uimanager.so although there exists ReactAndroid::react_nativemodule_core prefab with react_nativemodule_core.so?

We can definitely expose also libreact_render_uimanager as prefab libraries (along to react_render_scheduler and react_render_mounting as you requested). Please note, that in the future we might consolide all the libraries into a single one for the sake of semplicity (which is going to be a breaking change in terms of the prefab module names, we'll communicate this properly if we plan to do so).

2. Missing nested header files

You're right in the sense that react_nativemodule_core is a kind of a 'complicated' library. I wish we coudl get rid of it entirely. Sadly this is more of a complex task and for the time being I looked into including only the headers that were necessary for the template to run to prefab-ify react_nativemodule_core.
I can totally add the missing headers to react_nativemodule_core. This will have the side effect of increasing a bit the .aar size, but given your error messages, it seems like the list of headers to had is quite small.

For reference, the list of headers we pack with react_nativemodule_core is defined here:
https://github.com/facebook/react-native/blob/25132c8490ca2d4a9e64ce26413a9a854187adca/ReactAndroid/build.gradle#L141

3. Missing shared libraries

I can look into preffab-ify also those 3 libraries reactnativejni, jscexecutor, and hermes-executor-debug. The last one is going to be the hardest as this library has different name based on flavor (hermes-executor-debug vs hermes-executor-release which is something quite intricate to handle).

[tomekzaw]

@cortinico Thanks for the detailed answer!

Just to give you a small bit of context, the current set of libraries that we decided to prefab-ify, was mostly guidaded by the new app template. I essentally migrated library one by one, till the new app template was effectively running only on prefabbed libraries. If a library was left out, it's mostly because the sample app is not linking against it. Nothing prevents us from prefabbing it as well.

Yeah, that makes sense, thanks.

We can definitely expose also libreact_render_uimanager as prefab libraries (along to react_render_scheduler and react_render_mounting as you requested).

Yes, please expose them! 😄 Based on the list of headers I thought that these three shared libraries (i.e. uimanager, scheduler and mounting) are already included within react_nativemodule_core, but now it makes sense why this trio was still required.

Please note, that in the future we might consolide all the libraries into a single one for the sake of semplicity (which is going to be a breaking change in terms of the prefab module names, we'll communicate this properly if we plan to do so).

Sure, this sounds like a simple change for us, just wondering if it wouldn't be easier for everyone to do it before 0.71.0, but I understand the issue might be too complex to address it right away.

I can totally add the missing headers to react_nativemodule_core. This will have the side effect of increasing a bit the .aar size, but given your error messages, it seems like the list of headers to had is quite small.

Honestly I don't know which approach is recommended (minimal vs. recursive headers). Assume there are two prefabs, B and C, which both rely on A. It makes sense to include headers for A both in B and C for the sake of ease of use, but I agree that it leads to a slight increase of AAR size due to duplication of files in the final artifact. It's not a problem for us to include some additional prefabs just for headers, just wondering what's the industry standard.

I can look into preffab-ify also those 3 libraries reactnativejni, jscexecutor, and hermes-executor-debug.

It would be great, thanks! This will unblock the prefab migration for Reanimated.

[cortinico]

Sure, this sounds like a simple change for us, just wondering if it wouldn't be easier for everyone to do it before 0.71.0

I've decided to don't do this for .71 as handling the prefab work was already a challenge (as you see all those PrefabPreprocessingEntry needs supporting infra to 'prepare' the headers to be prefab-ready).

Consolidating into a single shared library will have to be investigated as it will have implications on final app size + runtime that we didn't want to rush into .71, given the amount of changes already shipped.

Honestly I don't know which approach is recommended (minimal vs. recursive headers).

Here my opinion is that us (RN) we should avoid having transitive dependencies between headers as much as possible. The problem is like for libraries like boost that add quite a lot of spaces to the .aar, we can't just duplicate the headers over and over in all the libraries that are using it.
So in general, the 'recursive headers' approach is the one I would suggest. Still, the root cause is that react_nativemodule_core is not self contained and should probably be nuked.

[cortinico]

All the requested missing features have been implemented. They're available in the latest nightly and will be shipped in RC3: facebook/react-native#35510

[kelset]

thanks for reporting! @NickGerleman any insights into what might have gone wrong here?

[NickGerleman]

Yeah, it looks like facebook/react-native@d4220cc was an incorrect cherry-pick (AFoxman renamed the package after the cut, and the cherry-pick is using the new package name instead of the 0.71 one)

[NickGerleman]

Maybe a good example of something we could avoid if the cherry-pick process could be done by change authors. E.g. going back to the example of backport PRs/author commits to the branch.

[kelset]

it's my bad, I resolved badly the cherry-pick merge conflict when was handling it. We'll address in RC5. Thanks for all the help!

[NickGerleman]

Lol there is one more change to add missing methods after I realized I missed migrating the inline jsx in the AccessibilityInfo page. I already have quite the list here, and am about to go on break, but that one wouldn't be bad to cherry-pick as well if it is merged by the time the others are being picked. cc @kelset

[kelset]

@NickGerleman do you have the link to this 13th commit?

[kelset]

ok looks like it's probably this one facebook/react-native@76a1445

[cortinico]

@kelset I've updated the discussion on top including the missing items

[kelset]

cheers!

[retyui]

Here is a small fix for iOS builds when NO_FLIPPER=1

facebook/react-native#35686

[cipolleschi]

Added!

[Kudo]

please help to have this one: facebook/react-native@5eb25d2

[kelset]

@Kudo would it be ok if it's in 0.71.1? How high priority/blocking is this issue?

[Kudo]

@kelset totally fine. we have a workaround toward that and could remove the workaround later when the change is released.

[vickz84259]

Hey, I just wanted to know, approximately when will this version get published? The ticket linked to the blocking issue has been labeled as fixed. So, I can't seem to find anything else that's holding up this from being released.

(P.S: I'm unfamiliar with the release process. I am just curious if there's some other checks/processes that are already underway to get version 0.71.0 released)

[kelset]

hey there - we are in the process of finalising everything, and we are expecting 0.71.0 to land next week. Because of the recent CircleCI incident we had to rotate all the secrets so we'll do one last RC6 to quickly verify that all the processes are still working then do 0.71.0 soon after.

[vickz84259]

Thank you for the info. Have a good day.

[emanuelasistensi]

hey there - we are in the process of finalising everything, and we are expecting 0.71.0 to land next week. Because of the recent CircleCI incident we had to rotate all the secrets so we'll do one last RC6 to quickly verify that all the processes are still working then do 0.71.0 soon after.

Hello, any news if it will come out this week? Thank you.

[kelset]

ask me again in 10 mins ;)

[emanuelasistensi]

Excellent, I already saw it in npm, thank you very much.

[lukebars]

I guess you could do that yourself, as both versions are available for you to access

[Kudo]

this thread is for react-native release which is not related to expo.
expo will officially support react-native 0.71 in expo sdk 48. but if you have expo@47.0.12, that may support 0.71 as well.

[wood1986]

Please include this tiny fix in 0.71.0 facebook/react-native#35705

[cipolleschi]

Hi @wood1986, we are very close to release 0.71.0. Is it ok if we include this fix in 0.71.1?

[kelset]

please open a separate issue on the main repo for this, it needs more info so that it can be investigated accordingly

[varemenos]

You can hide this thread, I've figured out the issue.
We were using custom build types based on the two built-in ones (debug, release) instead of creating flavors of them.