-
-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to RN v0.62 #3782
Comments
One thing v0.62 is projected to get us is the latest version of the React Developer Tools. See #3801, our docs here, and the react-devtools v4 release notes. |
EDIT: There are places other than jsonable.js to which potential improvements are applicable. (I've generally been marking these with comments containing the string EDIT (Chris): facebook/flow#6715 ("Spreading into an object allows a value of undefined for subsequent properties"), as Ray pointed at #4046 (comment); he reports that this is fixed in v0.111.1. |
Upstream's list of breaking changes is short, and from a quick grep we don't appear to be affected by any of them. Advertised improvements include:
|
I think facebook/react-native@3a66fc7 may have been mistakenly released in RN v0.61 instead of v0.62. It includes some changes to the template app that we've therefore decided not to take as part of the v0.60 -> v0.61 upgrade, as noted at #3781 (comment). So we'll need to do that as part of the v0.62 upgrade. See also discussion. |
Just a note so we don't forget it — there's a handy guide, with screenshots, to changing some things via the Xcode UI, at react-native-community/upgrade-support#13. |
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
Although we should always do our best to keep up with the latest versions of all our dependencies, it initially appears that the list of ones we'll be required to upgrade, for RN v0.62 compatability, is short! Just to see whether the list was long or short, I tried upgrading to v0.62 on a local branch and handled peer dependency warnings one by one. (Of course, there could still be issues that aren't declared in peer dependencies.)
|
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
A reversion of e40c020 and 62621ef. Unfortunately, Jest 26 (the latest), which we'll take in an upcoming commit, doesn't support `jest-expo` at 37 [1]. We can't go past 37 (e.g., to 38.0.2, the latest) until we upgrade to React Native v0.62 (that's zulip#3782). That's because jest-expo's "react" peer dependency was bumped from ~16.9.0 to ~16.11.0 in expo/expo#8310 [2], and we must do that React upgrade atomically with our RN upgrade. The "react-native" peer dependency wasn't touched; it remained at "*". So, I'm left unsure whether it was intentional to drop support for RN v0.61 [3]. Ah well. As we were aware in e40c020: """ If `jest-expo` turns out to be buggy, or the dependency requirements get even more tangled or burdensome, we should feel free to abandon this effort; it's not terrible to have to add boring mocks. """ We may consider adding it back in as a followup to zulip#3782. Run our usual `yarn yarn-deduplicate && yarn`, as prompted by `tools/test deps`. [1] We get errors about jest-expo using `require.requireActual`, which was removed in jestjs/jest#9854, out in v26.0.0-alpha.0. [2] expo/expo@a4cabf30a#diff-4a85ebd1069aff25ee2e5f2b004281ccR33 [3] See react-native-webview/react-native-webview#1445.
With Flow v0.113.0, which we'll get in the RN v0.61 -> v0.62 upgrade (zulip#3782), red flags are raised about this test. Strangely, the test was allowed to expect the `zulipVersion` on an Account to be undefined. In fact, the type for it is `ZulipVersion | null`. The test is based on the false premise that a REALM_INIT action might not have a `zulipVersion` property. `RealmInitAction` states that it will always be there, as a ZulipVersion instance. So, delete the test. If we ever find that there's a legitimate case where it is missing, we'll fix the RealmInitAction type accordingly, and a new test can proceed from there.
With Flow v0.113.0, which we'll get in the RN v0.61 -> v0.62 upgrade (zulip#3782), red flags are raised about this test. Strangely, the test was allowed to expect the `zulipVersion` on an Account to be undefined. In fact, the type for it is `ZulipVersion | null`. The test is based on the false premise that a REALM_INIT action might not have a `zulipVersion` property. `RealmInitAction` states that it will always be there, as a ZulipVersion instance. So, delete the test. If we ever find that there's a legitimate case where it is missing, we'll fix the RealmInitAction type accordingly, and a new test can proceed from there.
With Flow v0.113.0, which we'll get in the RN v0.61 -> v0.62 upgrade (zulip#3782), red flags are raised about this test. Strangely [1], the test was allowed to expect the `zulipVersion` on an Account to be undefined. In fact, the type for it is `ZulipVersion | null`. The test is based on the false premise that a REALM_INIT action might not have a `zulipVersion` property. `RealmInitAction` states that it will always be there, as a ZulipVersion instance. So, delete the test. If we ever find that there's a legitimate case where it is missing, we'll fix the RealmInitAction type accordingly, and a new test can proceed from there. [1] I think the culprit is very likely facebook/flow#6715, which Ray reported as being fixed in Flow v0.111.1, at zulip#4046 (comment)
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
With Flow v0.113.0, which we'll get in the RN v0.61 -> v0.62 upgrade (zulip#3782), red flags are raised about this test. Strangely [1], the test was allowed to expect the `zulipVersion` on an Account to be undefined. In fact, the type for it is `ZulipVersion | null`. The test is based on the false premise that a REALM_INIT action might not have a `zulipVersion` property. `RealmInitAction` states that it will always be there, as a ZulipVersion instance. So, delete the test. If we ever find that there's a legitimate case where it is missing, we'll fix the RealmInitAction type accordingly, and a new test can proceed from there. [1] I think the culprit is very likely facebook/flow#6715, which Ray reported as being fixed in Flow v0.111.1, at zulip#4046 (comment)
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue zulip#3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
Until Flow v0.111.0 or later, where we'll be when we upgrade to React Native v0.62.0 (that's issue #3782), exact object types with indexer properties are broken. See more details in src/utils/jsonable.js. In particular, this will help us get userHelpers-test.js type-checked.
At #4101 (comment) , we just learned of another nice thing we'll get with this upgrade: the newer Flow version will support method calls in optional chains, like |
A reversion of e40c020 and 62621ef. Unfortunately, Jest 26 (the latest), which we'll take in an upcoming commit, doesn't support `jest-expo` at 37 [1]. We can't go past 37 (e.g., to 38.0.2, the latest) until we upgrade to React Native v0.62 (that's zulip#3782). That's because jest-expo's "react" peer dependency was bumped from ~16.9.0 to ~16.11.0 in expo/expo#8310 [2], and we must do that React upgrade atomically with our RN upgrade. The "react-native" peer dependency wasn't touched; it remained at "*". So, I'm left unsure whether it was intentional to drop support for RN v0.61 [3]. Ah, well. As I said in e40c020: """ If `jest-expo` turns out to be buggy, or the dependency requirements get even more tangled or burdensome, we should feel free to abandon this effort; it's not terrible to have to add boring mocks. """ We may consider adding it back in as a followup to zulip#3782. Run our usual `yarn yarn-deduplicate && yarn`, as prompted by `tools/test deps`. [1] We get errors about jest-expo using `require.requireActual`, which was removed in jestjs/jest#9854, out in v26.0.0-alpha.0. [2] expo/expo@a4cabf30a#diff-4a85ebd1069aff25ee2e5f2b004281ccR33 [3] See react-native-webview/react-native-webview#1445.
A reversion of e40c020 and 62621ef. Unfortunately, Jest 26 (the latest), which we'll take in an upcoming commit, doesn't support `jest-expo` at 37 [1]. We can't go past 37 (e.g., to 38.0.2, the latest) until we upgrade to React Native v0.62 (that's zulip#3782). That's because jest-expo's "react" peer dependency was bumped from ~16.9.0 to ~16.11.0 in expo/expo#8310 [2], and we must do that React upgrade atomically with our RN upgrade. The "react-native" peer dependency wasn't touched; it remained at "*". So, I'm left unsure whether it was intentional to drop support for RN v0.61 [3]. Ah, well. As I said in e40c020: """ If `jest-expo` turns out to be buggy, or the dependency requirements get even more tangled or burdensome, we should feel free to abandon this effort; it's not terrible to have to add boring mocks. """ We may consider adding it back in as a followup to zulip#3782. Run our usual `yarn yarn-deduplicate && yarn`, as prompted by `tools/test deps`. [1] We get errors about jest-expo using `require.requireActual`, which was removed in jestjs/jest#9854, out in v26.0.0-alpha.0. [2] expo/expo@a4cabf30a#diff-4a85ebd1069aff25ee2e5f2b004281ccR33 [3] See react-native-webview/react-native-webview#1445.
In the tradition of #3781 (comment) and #3548 (comment), here's a list of changes from the upgrade helper that we won't be doing as part of this upgrade: Platform-agnostic
Android
iOS
|
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper atomically with the main upgrade commit, and not before, just to be safe. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper atomically with the main upgrade commit, and not before, just to be safe. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper atomically with the main upgrade commit, and not before, just to be safe. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper atomically with the main upgrade commit, and not before, just to be safe. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper after the main upgrade commit, not before, just to be safe [5]. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499 [5] zulip#4244 (comment)
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper after the main upgrade commit, not before, just to be safe [5]. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499 [5] zulip#4244 (comment)
Marking as blocked on #4248; see discussion. |
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper after the main upgrade commit, not before, just to be safe [5]. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499 [5] zulip#4244 (comment)
Done as part of the RN v0.61 -> v0.62 upgrade. In this commit: - Part of the RN v0.60 -> v0.61 [sic] changes to the template app [1], corresponding to facebook/react-native@3a66fc7dc - A partial reversion of that, in the RN v0.61 -> v0.62 changes to the template app [2], corresponding to facebook/react-native@bb272bacc. It looks like this was prematurely released in RN v0.61 instead of RN v0.62 [3], the latter being where most sources claim Flipper support was added; a list of such sources is on CZO [4]. In that partial reversion, the initialize-Flipper function's only call site is removed. We'll re-enable Flipper after the main upgrade commit, not before, just to be safe [5]. That will correspond to facebook/react-native@05f5cb534. [1] https://react-native-community.github.io/upgrade-helper/?from=0.60.6&to=0.61.5 [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] zulip#3782 (comment) [4] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Flipper/near/900499 [5] zulip#4244 (comment)
Released 2020-03-26. Release notes:
https://reactnative.dev/blog/2020/03/26/version-0.62
and shorter version: https://github.com/facebook/react-native/releases/tag/v0.62.0
(
This is for a version that isn't released yet 🙂, so there's no work to do on it right now. Filing to have an identifier to refer to this upgrade by.)We also won't start real work on this upgrade until after #3781, the upgrade to RN v0.61, is complete.Which it is!Changes include:
foo?.bar()
The text was updated successfully, but these errors were encountered: