Upgrade to RN v0.64! #4991

…v0.64. This would be handled already if our transformIgnorePatterns extended the transformIgnorePatterns in React Native's Jest preset, because that preset was adapted in facebook/react-native@a77f2c40d, released in RN v0.64. It would also be handled already if our transformIgnorePatterns extended the transformIgnorePatterns in `jest-expo`'s Jest preset after *that* preset was adapted, in the (as-yet-unreleased) change in expo/expo@24bce422c. But we ignore and clobber transformIgnorePatterns in those presets, because the API just isn't suitable to taking a list from elsewhere and extending it [1]. So we add this line ourselves. Since we're upgrading RN before taking that `jest-expo` change, we'll see the following harmless warning for a while when we run Jest: react-native/jest-preset contained different transformIgnorePatterns than expected. It's harmless because we don't use `jest-expo`'s transformIgnorePatterns anyway; we fully specify our own instead. [1] zulip#4991 (comment) Related: zulip#4426

`jest-expo` has a bug where it imports `fbjs-scripts` library but doesn't declare it as a dependency. This hasn't caused any issues so far because React Native has been pulling in `fbjs-scripts`, and `jest-expo` uses it from there. But RN v0.64 stops pulling in `fbjs-scripts`, so things fail [1]. So, until we get a version of `jest-expo` that declares `fbjs-scripts` as a dependency, or (preferably) consumes the code from its new home at @jest/create-cache-key-function [2] (and hopefully declares *that* as a dependency), we should keep `fbjs-scripts` as our own direct dependency. Since this is meant to be a temporary state, and to keep down complexity, just pin to the exact version that RN pulls in in RN v0.63, which is 1.2.0. [1] expo/expo#13886 (comment) [2] See facebook/react-native@fd9787ecc.

In this commit: - Update `react-native`, `react`, and `flow-bin` in package.json, and bump the Flow version in the Flow config. All of this is normal. - Add a `resolutions` line for `react-test-renderer`, while we wait for `jest-expo` to officially target RN v0.64. I'd opened the relevant change in expo/expo#13549, but it landed first in expo/expo@d49e7070a. As of 2021-09-03, that change hasn't been released, but it might be soon. This line raises the following warning from Yarn: warning Resolution field "react-test-renderer@17.0.1" is incompatible with requested version "react-test-renderer@~16.11.0" This is expected. The doc says [1], "You will receive a warning if your resolution version or range is not compatible with the original version range." We've managed to get away with incompatible `resolutions` lines in the past; I guess that's a Yarn bug that we're not running into this time. - Enable `exact_by_default`, to follow facebook/react-native@050a7dd01. (We'd done a lot of work to prepare for this.) We couldn't enable it earlier because RN v0.63 didn't pass type-checking with it on. - Do two find-and-replace-all tasks, for some places where we're importing from React Native's internals and their paths have changed: 'react-native/Libraries/Animated/src/nodes/AnimatedValue' -> 'react-native/Libraries/Animated/nodes/AnimatedValue', from facebook/react-native@9c9e67791. 'react-native/Libraries/StyleSheet/StyleSheetTypes' -> 'react-native/Libraries/StyleSheet/StyleSheet' from facebook/react-native@0a6713312. And, for this one, they give the reason as "to encourage its use in product code"! 🎉 - And that's it! [1] https://classic.yarnpkg.com/en/docs/selective-version-resolutions/#toc-tips-tricks Fixes: zulip#4426

As planned; see the code comment.

We decided to postpone taking 4.0.1 or later until after the RN v0.64 upgrade. That's because someone reported an issue with 4.0.1 [1], and a supposed fix landed in facebook/react-native@53f55001a, which was a change to RN's internal code released in v0.64. Release notes here: https://developer.android.com/studio/releases/gradle-plugin#4-1-0 Quite a few major changes announced, hopefully they're all good ones. Our tests pass, and a debug build on Android built and ran fine for me. Part of the RN v0.63 -> v0.64 changes to the template app, corresponding to: facebook/react-native@cf8368f20 facebook/react-native@553fb8b28 facebook/react-native@dfa9db49e See discussion at https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Pin.20to.20explicit.20NDK.20version.3F/near/1210089. [1] facebook/react-native#29013 (comment)

Done to follow the template-app change in facebook/react-native@eb85d1dbd. Done after the RN v0.64 upgrade because Hermes on iOS is advertised as new in v0.64. We don't actually intend to use Hermes at all until RN v0.65, when it gains support for Intl when used on Android. Intl support on iOS is still under discussion, and they don't have a timeline yet: facebook/hermes#23 (comment)

These defaults are set in https://github.com/facebook/react-native/blob/v0.64.2/scripts/react_native_pods.rb: versions['Flipper'] ||= '~> 0.75.1' versions['Flipper-Folly'] ||= '~> 2.5.3' versions['Flipper-RSocket'] ||= '~> 1.3' We started pinning to some specific versions in 912cb9e, following published advice from RN in facebook/react-native#31480 for fixing a build issue with Xcode 12.5. Checking that advice again, its entry suggests that we don't have to do anything as long as we're at RN v0.64.1 or higher. Which makes sense, seeing those defaults.

Done to follow the template-app changes in facebook/react-native@5c09b3fb5 and facebook/react-native@ed237b479. Done after the RN v0.64 upgrade because the new code depends on changes to internal RN code (scripts/react_native_pods.rb). The two names refer to two different functions, and react_native_post_install is new in RN v0.64. That function calls flipper_post_install (if we've enabled Flipper by calling `use_flipper!`, that is), and it does some other stuff. That other stuff includes some changes to our project.pbxproj, apparently.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade to RN v0.64! #4991

Upgrade to RN v0.64! #4991

Commits on Sep 8, 2021