Should we release 0.69.2?

[fortmarek]

Released.

Please refer to #27 for follow ups

---

Should we release 0.69.2?

Current Release: 0.69.1

Conversations on this thread are limited:

• major release issues.
• qualified cherry-pick requests of commits on main that did not make the previous patch version.

Please include a link to the specific commit on main to be cherry-picked, for example: facebook/react-native@bd2b7d6

In other words, if you cannot point to a particular commit on main, then your request likely belongs as a new issue.
If the issue is a major release issues, please reference the issue here.

---

List of qualified picks

• facebook/react-native@0bd5239, facebook/react-native@9f112af (to be combined to a single PR for 0.69 specifically):
  • [fix] backport FlipperConfiguration from main facebook/react-native#34098 (hence, already in 0.69 branch)
• facebook/react-native@2fb6a33
• facebook/react-native@b5ff26b
• facebook/react-native@f97c6a5
• facebook/react-native@bd12e41
• facebook/react-native@4ea38e1 (might be already in 0.69.1?)
• fix(deps): react-shallow-renderer v16.15.0 for react v18 compat facebook/react-native#34104
• Upgrade RN CLI to v8.0.3 facebook/react-native#34159

Local commits to backport to main

[geraintwhite]

Can we cherry-pick the fix for jest 28 support? facebook/react-native@b5ff26b

[ginnymin]

+1 to this, I came here to ask the same!

[mikehardy]

We have some trouble brewing with the patch from @Kudo to fix the use_frameworks! + hermes_enabled = true case, reported by @raghavyadavm (thank you!):

facebook/react-native#34030 (comment)

it only shows up when you go turn it on a real device and sadly my qualification runs were done against Simulators 😞

[Updated: tested other scenarios. It's not a regression from 0.69.0, it is just a regression of expectations - we thought it would work - 0.69.0 did not work for use_frameworks at all, and 0.69.1 does not either]

This may be an issue that causes total failure on iOS builds to real devices on default configurations, so wanted to put a heads up here as a revert + 0.69.2 might be appropriate if someone else confirms the failure. At the very least it appears to cause failures to deploy on real iOS device for any use_frameworks! build

I'm checking other scenarios and will propose a revert PR for this against main (for cherry-pick here) as soon as I can since my first quick attempts at a repair were ineffective. Someone with more objective-c / cocoapods knowledge may know how to repair this really easily though of course, that would be much better and I'll happily see my revert PR closed

workarounds:

• If you disable bitcode, you can use_frameworks and have hermes either on or off, which is cool but disabling bitcode is a shame. and disabling bitcode will be the default in Xcode 14 so this is reasonable
• If you do a patch package that reverts Fix RCT-Folly build error when use_frameworks! and hermes are both enabled facebook/react-native#34030 + remove ios/Pods + pod install then you can do use_frameworks again 0.69.1, but no hermes

[cortinico]

Is this also causing issues like this one? facebook/react-native#34102

[mikehardy]

@cortinico not sure but I assume you post that here because you have a hunch it does - reading that issue it is the exact area being altered by the other related patch - facebook/react-native#34011 - but the "steps to reproduce" being really vague on that one and the multi-splat of screenshots vs text mean I'm not sure exactly. I won't have time to pursue either unfortunately, have to set react-native "integration / release-tester" work aside for a bit as I'm set for a batch of travel

[Arkkeeper]

I guess, your terminal tells something like "new NativeEventEmitter() was called with a non-null argument" at this time, right?

[kelset]

important one to not forget: we need a new CLI v8 release to fix the warn issue: #23 (comment)

[swrobel]

@thymikee not sure what would be useful to share, but with the same app on RN 0.67.4, I don't have any such issue. This only has come up since attempting the upgrade to 0.69.1.

$ node -v
v16.16.0

[thymikee]

I was able to repro that with this specific package, investigating now.

[thymikee]

Looks like it's related to this change in fortawesome v6: https://github.com/FortAwesome/Font-Awesome/blame/6.x/js-packages/%40fortawesome/free-brands-svg-icons/package.json#L50. Now that exports are defined explicitly, node can't resolve package.json, so it appends the .js as instructed by the ESM exports config. Not sure what was the idea behind it and whether this is something becoming a standard in the node.js community or not. This is the first time I encounter this. There are lots of other packages that query for <package-name>/package.json because it was always guaranteed to be there, so I assume it's a bug in the configuration. Please contact the library maintainers

[kelset]

@thymikee @swrobel looks like they are already aware: FortAwesome/Font-Awesome#18844 (comment)

[swrobel]

@thymikee @kelset thank you both for your quick responses, and my apologies for sending you down that rabbit hole - I forgot that I had upgraded my FontAwesome deps along with my RN version, so I wasn't comparing the two accurately. Upon reverting to the same versions I was using with RN 0.67.4, and using the updated RN 0.69.1 + cli 8.0.3 I'm now able to build my app. Thank you @thymikee for the fix!

[wood1986]

Hey is it possible to include this tiny bug fix in 0.69.2?

facebook/react-native#34096

[kelset]

we can try! link to commit: facebook/react-native@bd12e41

[kelset]

Another commit: facebook/react-native@4ea38e1

[thomazcapra]

Is the iOS 11 still supported after this update?

[kelset]

@thomazcapra no it's not: https://reactnative.dev/blog/2022/06/21/version-069#highlights-of-069

[AfrazHussain]

facebook/react-native#34102 is causing quite a lot of issues with existing libraries. There seems to be something wrong with React-bridging paths, and it only happens when you add a few external libraries - the one is the issue is react-native-vision-camera and the one that I have tested is @shopify/react-native-skia. Steps to reproduce and a few suggestions are mentioned in the issue.

P.S. I know I'm not cherry picking a PR but I'm just bringing it to everyone's attention for the 0.69.2 release.

[kelset]

this commit seems to be related: facebook/react-native@f97c6a5

[myckhel]

While testing out rn v0.69.1 on android with newArchEnabled=true and hermes enabled, i got this error in metro log.
I hope i didn't miss anything.

 ERROR  Invariant Violation: requireNativeComponent: "RCTView" was not found in the UIManager.

This error is located at:
    in RCTView (at View.js:32)
    in View (at createAnimatedComponent.js:211)
    in AnimatedComponent (at createAnimatedComponent.js:264)
    in AnimatedComponentWrapper (at TouchableOpacity.js:224)
    in TouchableOpacity (at TouchableOpacity.js:280)
    in TouchableOpacity (at LearnMoreLinks.js:92)
    in RCTView (at View.js:32)
    in View (at LearnMoreLinks.js:81)
    in LinkList (at App.js:86)
    in RCTView (at View.js:32)
    in View (at App.js:69)
    in RCTView (at View.js:32)
    in View (at ScrollView.js:1682)
    in RCTScrollView (at ScrollView.js:1800)
    in ScrollView (at ScrollView.js:1826)
    in ScrollView (at App.js:65)
    in RCTView (at View.js:32)
    in View (at SafeAreaView.js:41)
    in SafeAreaView (at App.js:63)
    in App (at renderApplication.js:50)
    in RCTView (at View.js:32)
    in View (at AppContainer.js:92)
    in RCTView (at View.js:32)
    in View (at AppContainer.js:119)
    in AppContainer (at renderApplication.js:43)
    in AwesomeProject(RootComponent) (at renderApplication.js:60), js engine: hermes

[mikehardy]

If no one else has replied yet, we probably need the package.json and an App.js for reproduction

[myckhel]

Well i didnt add any package or change the content of App.js after initing the RN template.
Its same content as the one in the rn v0.69.1 template.

[mikehardy]

@myckhel interesting! That's important to know. So basically a reproduction would be:

• npx react-native init MetroNotWorking
• edit android to enable new architecture, enable hermes
• npx react-native start
• npx react-native run-android

Nothing else is needed?

(https://stackoverflow.com/help/how-to-ask / https://stackoverflow.com/help/mcve)

[myckhel]

Yes correct 👍🏽

[joe-sam]

This hack fixed my new architecture build issues (using the 2022 VisualStudio developer terminal)
From Windows OS limit path issue
Adding the following fixed it for me:
In the project level build.gradle
Line 1

+ import org.apache.tools.ant.taskdefs.condition.Os

Line 19 or after the first System.properties check (depending on your config)

if (System.properties['os.arch'] == "aarch64") {
   // For M1 Users we need to use the NDK 24 which added support for arch64
   ndkVersion = "24.0.8215888"
+} else if (Os.isFamily(Os.FAMILY_WINDOWS)) {
+   // For Windows Users, we need to use NDK 23, otherwise the build will
+   // fail due to paths longer than the OS limit
+   ndkVersion = "23.1.7779620"
} else {
   // Otherwise we default to the side-by-side NDK version from AGP.
   ndkVersion = "21.4.7075529"
}

[mikehardy]

@cortinico something really strange happened here on this file!

• the M1 fix to use NDK24 is in (on 069-release and main)

facebook/react-native@4befd2a

• the Windows fix to use NDK23 was in, but ... was clobbered somehow and is no longer in on 069-release or main!

commit facebook/react-native@e48a580
main https://github.com/facebook/react-native/blame/main/template/android/build.gradle
https://github.com/facebook/react-native/blob/0.69-stable/template/android/build.gradle

The git blame on that one is really strange, when going back through history, I can't figure out exactly what happened really.

Looks like 24 or a regedit (i.e., CLI doctor check in future?) might work for windows

Either way windows build broken without a fixup here I think

[kelset]

looks like it was removed here facebook/react-native@7b76abc I'll ask during the sync

[mikehardy]

Oh yes - there were a series of changes here probing different styles. I may have been mentally stuck on an intermediate step. I'm certain Nicola will know much better than me here

[kelset]

yeah so the update here is that basically NDK 23 and 24 are very unstable on Win, which is why in that commit the workaround to add NDK23 was removed

[cortinico]

I'm certain Nicola will know much better than me here

Sorry I missed this ping.
While working on Windows support, we initially thought NDK 23 would help fix the long path issues. This turned out to not be the case and we reverted the if-then-else to NDK 21 as 23/24 were really unstable on Windows and leading to a lot of Bsod.