Upgrade to RN v0.61 #3781
Comments
gnprice
added
the
blocked on other work
|
(edit: mistaken, thankfully -- see #3781 (comment)) Debugger warnings in RN 0.60 indicate that the React |
|
One exciting change is that this old RN bug is reportedly fixed in v0.61!
That's the mitigated version of the RN bug that got much worse back in v0.55 (vs. v0.54 and earlier), which our users experienced as #2589. I fixed that one upstream so that in v0.56 it was back to the level of v0.55 and earlier; but it's encouraging that the underlying bug now seems to be fixed too. (Though there's still some uncertainty because, as discussed on that issue thread, nobody knows how it got fixed. 🤞 ) |
|
I think it's likely that this upgrade will turn out to be a lot less work than the v0.60 upgrade (or the v0.59 upgrade before that.) My information on this is circumstantial: it seems like for whatever reason a lot of people are (at least as of like a month ago) still on v0.59, and a lot are on v0.61 or v0.62, and very few are on v0.60. My data for that is from being subscribed to an RN issue thread where a few people a month report it's still broken for them, and I noticed sometime like a month ago that the reports in 2020-to-date or so followed that pattern. (Originally mentioned this the other day in chat.) So, hopefully it turns out that way when we go to try it! |
gnprice
removed
the
blocked on other work
This isn't correct. Here's the warning:
As the linked article explains, this is a React warning, and the "next major version" in question is React 17. There is not yet a React 17, so RN v0.61 doesn't use it. Nor does RN v0.62 (which is out already), or v0.63 (which has a release candidate out.) |
|
EDIT: This has been resolved. Thanks, @gnprice! I commented at #3635 (comment) about some new errors I'm seeing with Flow 105; it looks like that PR would make things more sensible in a way that probably eliminates those errors. 🙂 |
|
Similarly to #3548 (comment), this comment lists the changes that appear in the upgrade helper but that we don't do in this series. Making this list is essential to make sure we don't miss anything, but putting it here instead of in commit messages will help avoid over-crowding the commit messages. Platform-agnostic
Android
iOS
|
It's a build system: https://buck.build/. It's closely related to Bazel -- Buck is the result of ex-Googlers at Facebook reimplementing Google's internal build system called Blaze, and a few years later Google open-sourced Blaze and called it Bazel. It's probably a fine system, but the open-source RN ecosystem uses Gradle and not Buck, so it wouldn't make sense for us to use it -- we'd have to manually maintain Buck config for each dependency that has any Android-native pieces. Really it doesn't make much sense to me why there's a Buck config in the template app, because the number of people who've benefited from that template file has got to be approximately zero. (I assume that inside Facebook, they do use Buck for their RN. I think they use it for just about everything else.) |
Goodness gracious, this is frighteningly fast, at least in my testing on iOS. Glad to see this. 🙂 |
|
Hot Reload almost never worked for me! I'm eagerly waiting to test Fast Refresh! 😀 |
The immediate need is to set up a way to mock the new `ZLPConstants` in `NativeModules`, which we'll do in an upcoming commit. Doing this, as recommended by React Native [1], also means we're better prepared for the React Native v0.61 upgrade (zulip#3781), in which Haste is removed [2]. A consequence of that removal, it seems, is that mocks like this one, which we have now: ``` jest.mock('Linking', () => { ... }` ``` , won't work. Several people have handled this by changing 'Linking' to something like 'react-native/Libraries/Linking/Linking', but this is brittle because it couples our tests with the current directory structure in 'react-native'. Better to do it this way. We considered following the advice of others at that issue, including a blog post [3] responding to the official suggestion with an alternative. But we didn't reproduce the problems the post's author mentioned, and we've so far been able to explain the hiccups we've seen. [1] facebook/react-native#26579 (comment) [2] facebook/react-native#26579 (comment) [3] facebook/react-native#26579 (comment)
Doing this, as recommended by React Native [1], means we're better prepared for the React Native v0.61 upgrade (zulip#3781), in which Haste is removed [2]. A consequence of that removal, it seems, is that mocks like this one, which we have now: ``` jest.mock('Linking', () => { ... }` ``` , won't work. Several people have handled this by changing 'Linking' to something like 'react-native/Libraries/Linking/Linking', but this is brittle because it couples our tests with the current directory structure in 'react-native'. Better to do it this way. We considered following the advice of others at that issue, including a blog post [3] responding to the official suggestion with an alternative. But we didn't reproduce the problems the post's author mentioned, and we've so far been able to explain the hiccups we've seen. [1] facebook/react-native#26579 (comment) [2] facebook/react-native#26579 (comment) [3] facebook/react-native#26579 (comment)
The immediate need is to set up a way to mock the new `ZLPConstants` in `NativeModules`, which we'll do in an upcoming commit. Doing this, as recommended by React Native [1], also means we're better prepared for the React Native v0.61 upgrade (zulip#3781), in which Haste is removed [2]. A consequence of that removal, it seems, is that mocks like this one, which we have now: ``` jest.mock('Linking', () => { ... }` ``` , won't work. Several people have handled this by changing 'Linking' to something like 'react-native/Libraries/Linking/Linking', but this is brittle because it couples our tests with the current directory structure in 'react-native'. Better to do it this way. We considered following the advice of others at that issue, including a blog post [3] responding to the official suggestion with an alternative. But we didn't reproduce the problems the post's author mentioned, and we've so far been able to explain the hiccups we've seen. [1] facebook/react-native#26579 (comment) [2] facebook/react-native#26579 (comment) [3] facebook/react-native#26579 (comment)
Using the RN Upgrade Helper, a web app showing the diff from the release/0.60.6 and the release/0.61.5 branches of the `react-native-community/rn-diff-purge` repo, at https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5. In this commit: - Upgrade `react-native`, `react`, and `flow-bin` following the template - Change our Podfile to reflect new/changed iOS dependencies in RN, following the template - Make changes to adapt to multiple upgrades of RN's Hermes dependency (details below) - Run `yarn yarn-deduplicate && yarn` as prompted by `tools/test deps` See (on the issue) a list of changes from the upgrade helper that we don't do in this series [1]. Hermes details: In facebook/react-native@c21e36db4, React Native started using v0.1.1 of Hermes [2], which includes a rename of the NPM package (facebook/hermes@c74842e) from 'hermesvm' to 'hermes-engine'. So, use the new path in the one place where its path occurs in our code, following the changes to the template in that commit. In facebook/react-native@06c64f5f1, React Native started using v0.2.1 of Hermes [3], which was came with the announcement, "The C++ runtime library is now packaged in a separate AAR to avoid `pickFirst` nondeterminisms". Follow the changes to the template in that commit, where several `pickFirst` lines are removed. [1]: zulip#3781 (comment) [2]: https://github.com/facebook/hermes/releases/tag/v0.1.1 [3]: https://github.com/facebook/hermes/releases/tag/v0.2.1 Fixes: zulip#3781
Doing this, as recommended by React Native [1], means we're better prepared for the React Native v0.61 upgrade (zulip#3781), in which Haste is removed [2]. A consequence of that removal, it seems, is that mocks like this one, which we have now: ``` jest.mock('Linking', () => { ... }` ``` , won't work. Several people have handled this by changing 'Linking' to something like 'react-native/Libraries/Linking/Linking', but this is brittle because it couples our tests with the current directory structure in 'react-native'. Better to do it this way. We considered following the advice of others at that issue, including a blog post [3] responding to the official suggestion with an alternative. But we didn't reproduce the problems the post's author mentioned, and we've so far been able to explain the hiccups we've seen. [1] facebook/react-native#26579 (comment) [2] facebook/react-native#26579 (comment) [3] facebook/react-native#26579 (comment)
Using the RN Upgrade Helper, a web app showing the diff from the release/0.60.6 and the release/0.61.5 branches of the `react-native-community/rn-diff-purge` repo, at https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5. In this commit: - Upgrade `react-native`, `react`, and `flow-bin` following the template - Change our Podfile to reflect new/changed iOS dependencies in RN, following the template - Make changes to adapt to multiple upgrades of RN's Hermes dependency (details below) - Run `yarn yarn-deduplicate && yarn` as prompted by `tools/test deps` See (on the issue) a list of changes from the upgrade helper that we don't do in this series [1]. Hermes details: In facebook/react-native@c21e36db4, React Native started using v0.1.1 of Hermes [2], which includes a rename of the NPM package (facebook/hermes@c74842e) from 'hermesvm' to 'hermes-engine'. So, use the new path in the one place where its path occurs in our code, following the changes to the template in that commit. In facebook/react-native@06c64f5f1, React Native started using v0.2.1 of Hermes [3], which was came with the announcement, "The C++ runtime library is now packaged in a separate AAR to avoid `pickFirst` nondeterminisms". Follow the changes to the template in that commit, where several `pickFirst` lines are removed. [1]: zulip#3781 (comment) [2]: https://github.com/facebook/hermes/releases/tag/v0.1.1 [3]: https://github.com/facebook/hermes/releases/tag/v0.2.1 Fixes: zulip#3781
Using the RN Upgrade Helper, a web app showing the diff from the release/0.60.6 and the release/0.61.5 branches of the `react-native-community/rn-diff-purge` repo, at https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5. In this commit: - Upgrade `react-native`, `react`, and `flow-bin` following the template - Change our Podfile to reflect new/changed iOS dependencies in RN, following the template - Make changes to adapt to multiple upgrades of RN's Hermes dependency (details below) - Run `yarn yarn-deduplicate && yarn` as prompted by `tools/test deps` See (on the issue) a list of changes from the upgrade helper that we don't do in this series [1]. Hermes details: In facebook/react-native@c21e36db4, React Native started using v0.1.1 of Hermes [2], which includes a rename of the NPM package (facebook/hermes@c74842e) from 'hermesvm' to 'hermes-engine'. So, use the new path in the one place where its path occurs in our code, following the changes to the template in that commit. In facebook/react-native@06c64f5f1, React Native started using v0.2.1 of Hermes [3], which was came with the announcement, "The C++ runtime library is now packaged in a separate AAR to avoid `pickFirst` nondeterminisms". Follow the changes to the template in that commit, where several `pickFirst` lines are removed. [1]: zulip#3781 (comment) [2]: https://github.com/facebook/hermes/releases/tag/v0.1.1 [3]: https://github.com/facebook/hermes/releases/tag/v0.2.1 Fixes: zulip#3781
Using the RN Upgrade Helper, a web app showing the diff from the release/0.60.6 and the release/0.61.5 branches of the `react-native-community/rn-diff-purge` repo, at https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5. In this commit: - Upgrade `react-native`, `react`, and `flow-bin` following the template - Change our Podfile to reflect new/changed iOS dependencies in RN, following the template - Make changes to adapt to multiple upgrades of RN's Hermes dependency (details below) - Run `yarn yarn-deduplicate && yarn` as prompted by `tools/test deps` See (on the issue) a list of changes from the upgrade helper that we don't do in this series [1]. Hermes details: In facebook/react-native@c21e36db4, React Native started using v0.1.1 of Hermes [2], which includes a rename of the NPM package (facebook/hermes@c74842e) from 'hermesvm' to 'hermes-engine'. So, use the new path in the one place where its path occurs in our code, following the changes to the template in that commit. In facebook/react-native@06c64f5f1, React Native started using v0.2.1 of Hermes [3], which was came with the announcement, "The C++ runtime library is now packaged in a separate AAR to avoid `pickFirst` nondeterminisms". Follow the changes to the template in that commit, where several `pickFirst` lines are removed. [1]: zulip#3781 (comment) [2]: https://github.com/facebook/hermes/releases/tag/v0.1.1 [3]: https://github.com/facebook/hermes/releases/tag/v0.2.1 Fixes: zulip#3781
We won't meaningfully start on this until we complete the upgrade to RN v0.60, #3548. Filing to have an identifier to refer to.(We're now on v0.60.)Released 2019-09. Release notes here:
https://facebook.github.io/react-native/blog/2019/09/18/version-0.61
Exciting improvements include:
implicit-inexact-objectflowlint (which will help with some later steps of Convert all object types to exact, or explicitly-inexact #3452)Possible incompatible changes, requiring work from us on upgrade, include:
The text was updated successfully, but these errors were encountered: