Upgrade to RN v0.68 #5344
Comments
gnprice
added
upstream: RN
|
This looks like more changes than v0.67 (I say having read the full changelog, but not looked at any of the code yet), but still no obvious obstacles. Other than one: it does sound like it'll probably require the Gradle and AGP upgrades, #5377. |
Following the "Bare workflow" instructions for upgrading: https://blog.expo.dev/expo-sdk-45-f4e332954a68#5954 As with the last one, 44 in 3edc37a, the `expo upgrade` command went through a phase it described as "Updating packages to compatible versions (where known)," and that changed several of our dependency ranges, even of non-Expo things. (For speculation on what that phase is about, see 3edc37a.) We rejected version-range changes to these libraries that would have resulted in downgrades to the libraries' resolved versions: - react-native-safe-area-context from 4.3.1 to 4.2.4 - react-native-screens from 3.13.1 to 3.11.1 - react-native-webview from 11.22.2 to 11.18.1 We rejected upgrades to @react-native-community/netinfo and react-native-reanimated for the reasons we gave in the Expo 44 upgrade; see those at zulip#5441 (comment) . And we rejected bumping react-native from 0.67.4 to 0.68.2, with optimism that we can get this Expo upgrade done before that RN upgrade, which is zulip#5344. We took the rest. In the step > Update your `App.Delegate.mm` (you should have moved from .m to > .mm in the previous step) according to this diff , the indicated changes just seemed to be the same changes we applied in the Expo 44 upgrade (3edc37a), just rebased atop a RN v0.68 upgrade. (The ".m" to ".mm" change is an example of that.) When we do the RN v0.68, we should study some special code that Expo wants us to add as part of that upgrade, beyond what the RN template app says. But that's a job for later, and I didn't see anything to do right now in this item. I tested basic functionality on my iPhone 13 Pro running iOS 15.6, and on the office Android device, a Samsung Galaxy S9 running Android 9. I didn't see any problems with building or running.
Following the "Bare workflow" instructions for upgrading: https://blog.expo.dev/expo-sdk-45-f4e332954a68#5954 As with the last one, 44 in 3edc37a, the `expo upgrade` command went through a phase it described as "Updating packages to compatible versions (where known)," and that changed several of our dependency ranges, even of non-Expo things. (For speculation on what that phase is about, see 3edc37a.) We rejected version-range changes to these libraries that would have resulted in downgrades to the libraries' resolved versions: - react-native-safe-area-context from 4.3.1 to 4.2.4 - react-native-screens from 3.13.1 to 3.11.1 - react-native-webview from 11.22.2 to 11.18.1 We rejected upgrades to @react-native-community/netinfo and react-native-reanimated for the reasons we gave in the Expo 44 upgrade; see those at zulip#5441 (comment) . And we rejected bumping react-native from 0.67.4 to 0.68.2, with optimism that we can get this Expo upgrade done before that RN upgrade, which is zulip#5344. We took the rest. In the step > Update your `App.Delegate.mm` (you should have moved from .m to > .mm in the previous step) according to this diff , the indicated changes just seemed to be the same changes we applied in the Expo 44 upgrade (3edc37a), just rebased atop a RN v0.68 upgrade. (The ".m" to ".mm" change is an example of that.) When we do the RN v0.68, we should study some special code that Expo wants us to add as part of that upgrade, beyond what the RN template app says. But that's a job for later, and I didn't see anything to do right now in this item. I tested basic functionality on my iPhone 13 Pro running iOS 15.6, and on the office Android device, a Samsung Galaxy S9 running Android 9. I didn't see any problems with building or running.
|
expo/expo@75e2cf7e3 claims that RN 68 will break animated GIF support unless we upgrade Fresco on Android to 2.5.0. |
|
When doing this upgrade, we should also examine changes to |
Following the "Bare workflow" instructions for upgrading: https://blog.expo.dev/expo-sdk-45-f4e332954a68#5954 As with the last one, 44 in 3edc37a, the `expo upgrade` command went through a phase it described as "Updating packages to compatible versions (where known)," and that changed several of our dependency ranges, even of non-Expo things. (For speculation on what that phase is about, see 3edc37a.) We rejected version-range changes to these libraries that would have resulted in downgrades to the libraries' resolved versions: - react-native-safe-area-context from 4.3.1 to 4.2.4 - react-native-screens from 3.13.1 to 3.11.1 - react-native-webview from 11.22.2 to 11.18.1 We rejected upgrades to @react-native-community/netinfo and react-native-reanimated for the reasons we gave in the Expo 44 upgrade; see those at zulip#5441 (comment) . And we rejected bumping react-native from 0.67.4 to 0.68.2, with optimism that we can get this Expo upgrade done before that RN upgrade, which is zulip#5344. We took the rest. For the step > Update your `App.Delegate.mm` (you should have moved from .m to > .mm in the previous step) according to this diff , we found that we'd already taken some of those changes when Expo backported them to the Expo 44 template app. Others, like the .m to .mm rename, we'd like to postpone until we do the RN 68 upgrade. A full audit of Expo's template-app commits from 44 to 45 found no changes we'd be interested in applying, except some related to RN 68 that we'd like to do with that upgrade; I've mentioned those on our RN 68 upgrade issue. See: zulip#5507 (comment) I tested basic functionality on my iPhone 13 Pro running iOS 15.6, and on the office Android device, a Samsung Galaxy S9 running Android 9. I didn't see any problems with building or running.
Following the "Bare workflow" instructions for upgrading: https://blog.expo.dev/expo-sdk-45-f4e332954a68#5954 As with the last one, 44 in 3edc37a, the `expo upgrade` command went through a phase it described as "Updating packages to compatible versions (where known)," and that changed several of our dependency ranges, even of non-Expo things. (For speculation on what that phase is about, see 3edc37a.) We rejected version-range changes to these libraries that would have resulted in downgrades to the libraries' resolved versions: - react-native-safe-area-context from 4.3.1 to 4.2.4 - react-native-screens from 3.13.1 to 3.11.1 - react-native-webview from 11.22.2 to 11.18.1 We rejected upgrades to @react-native-community/netinfo and react-native-reanimated for the reasons we gave in the Expo 44 upgrade; see those at zulip#5441 (comment) . And we rejected bumping react-native from 0.67.4 to 0.68.2, with optimism that we can get this Expo upgrade done before that RN upgrade, which is zulip#5344. We took the rest. For the step > Update your `App.Delegate.mm` (you should have moved from .m to > .mm in the previous step) according to this diff , we found that we'd already taken some of those changes when Expo backported them to the Expo 44 template app. Others, like the .m to .mm rename, we'd like to postpone until we do the RN 68 upgrade. A full audit of Expo's template-app commits from 44 to 45 found no changes we'd be interested in applying, except some related to RN 68 that we'd like to do with that upgrade; I've mentioned those on our RN 68 upgrade issue. See: zulip#5507 (comment) I tested basic functionality on my iPhone 13 Pro running iOS 15.6, and on the office Android device, a Samsung Galaxy S9 running Android 9. I didn't see any problems with building or running.
|
OK, I spent some time this afternoon starting on this upgrade.
I plan to edit the list below with updates as I proceed. List of template-app changesPreparing the list: in a react-native checkout, then reformatted slightly: repo added to commit IDs, To review the changes in detail: Our own fix 🎉 returning to us from upstream
In the main upgrade commit
iOS changes
Android changes
Interesting for future, but nothing to do now
Not corresponding to changes for us to make
In original order, for reference
facebook/react-native@ba7424d4d RN: Normalize Prettier Configuration |
|
Great, thanks for taking this on! 🙂 I think it's helpful for you to do one now and then, so we can compare notes on the process. Here are a few small things from my notes (not having gone far in this upgrade yet), to add to what you've found above. Organized by which of your headings they apply under: iOS changes
Android changes
Not corresponding to changes for us to make
|
|
Thanks for those notes!
Yeah, agreed.
Hmm, indeed. Specifically it sets The other change I see is to // Force all our third-party dependencies to a sensible buildToolsVersion.
// What version should that be? It's whatever the Android plugin applied
// to our app project.
// …
subprojects {
// …
afterEvaluate {
if (project.hasProperty("android")) {
android.buildToolsVersion rootProject.ext.buildToolsVersion(And even that I'm pretty sure is only necessary because various RN-ecosystem dependencies copied a
This one looks like it deletes some lines in
Yep, agreed.
Will note these down, thanks. |
I scanned through these three, and they look like they're applying the changes from RN's own template app between 67 and 68. There is a lot there, and very little explanation. So I didn't attempt to read every line closely. But having just read through those RN template changes, these changes generally looked familiar from that. And on the other hand if there were some meaningful Expo-specific change buried inside one of those commits, that'd be pretty tough to find. It'd also be tough for a reviewer, or even the author, to find and think about… so one would have to wonder if it was even a fully intended change. I think we're best off just interpreting these as "do the RN upgrade according to the RN template changes." |
Hmm, it looks like in fact this is already broken! On the current release v27.196, on both iOS and Android. Repro: find some message with an animated GIF in it (first one I found was in Searching our tracker, this has happened a couple of times before — an RN upgrade breaks animated GIFs, until we upgrade Fresco: So I guess this should become something we make a practice of updating on RN upgrades. The recipe from those previous occasions is basically, look at this spot in the current docs:
So I guess that's the better recipe. Better still would be if RN gives us a reasonable way to say "just use whatever version it is that RN wants to use here". I'll do some brief scouting around for that, but my hopes aren't super high. |
This is the main upgrade commit for zulip#5344. Some follow-up steps remain to be done in the next few commits. In the template app, this corresponds to: * Numerous commits just bumping the `react-native` dependency * One commit bumping Metro: facebook/react-native@ea74c5797 Bump direct Metro dependencies to 0.67.0 * One commit updating AppDelegate.m: facebook/react-native@aef843bfe update jsBundleURLForBundleRoot in template project to correspond to an API change in RN itself: facebook/react-native@0912ee179 remove fallbackResource from RCTBundleURLProvider api Other changes: * Update Podfile.lock after `yarn install`. * We get to remove a Flow fixme, because it was (as hoped for) fixed in RN upstream: facebook/react-native@851e87a1a make Easing an object, not a class
|
OK! Sent #5610 for the upgrade. Updated the big comment above about template changes to reflect taking care of each of them. Also filed #5611 for one small followup from a pair of |
This is the main upgrade commit for #5344. Some follow-up steps remain to be done in the next few commits. In the template app, this corresponds to: * Numerous commits just bumping the `react-native` dependency * One commit bumping Metro: facebook/react-native@ea74c5797 Bump direct Metro dependencies to 0.67.0 * One commit updating AppDelegate.m: facebook/react-native@aef843bfe update jsBundleURLForBundleRoot in template project to correspond to an API change in RN itself: facebook/react-native@0912ee179 remove fallbackResource from RCTBundleURLProvider api Other changes: * Update Podfile.lock after `yarn install`. * We get to remove a Flow fixme, because it was (as hoped for) fixed in RN upstream: facebook/react-native@851e87a1a make Easing an object, not a class
The next round after #5232. Blog post here:
https://reactnative.dev/blog/2022/03/30/version-068
and more-detailed changelog:
https://github.com/facebook/react-native/blob/main/CHANGELOG.md#v0680
The text was updated successfully, but these errors were encountered: