deps: Upgrade to Expo SDK 44

[chrisbobbe]

Following the "bare workflow" instructions for upgrading:
https://blog.expo.dev/expo-sdk-44-4c4b8306584a#8ff0

Marking as a draft because I'd like to use tsflower for some of the dependencies I'm bumping here. 🙂 I've started a discussion. Done!

I've kicked the tires with this revision on iOS and Android, with and without "Debug JS Remotely" activated, and things seem fine.

[chrisbobbe]

From the commit message for the upgrade:

When I ran `expo upgrade`, it went through a phase it described as
"Updating packages to compatible versions (where known)." This
changed a lot of version ranges, even of non-Expo things like
react-native-reanimated. I kept some of these and ignored others,
and I plan to elaborate on these choices in the GitHub PR thread. I
didn't find more info in the CLI's docs about how it chooses these
upgrades. I believe the code is
  https://github.com/expo/expo-cli/blob/expo-cli%405.4.12/packages/expo-cli/src/commands/info/upgradeAsync.ts#L541-L597
and that
  https://github.com/expo/expo/blob/sdk-44/packages/expo/bundledNativeModules.json
gets consulted as part of that.

So, here is that elaboration. (Formatted for a commit message because that's where I thought I'd put it, before I decided it's just too long.)

Several proposed upgrades seemed fine to take without much
inspection. Here are some explanations for more interesting ones:

  expo-application: Major-version bump, but the only breaking change
    announced is dropping iOS 11 support, and we've done that:
      https://github.com/expo/expo/blob/main/packages/expo-application/CHANGELOG.md

  expo-screen-orientation:
    - We had upper-bounded this because expo-modules-core@0.6.0 was
      needed to avoid an error we saw with 4.1.0. We ran into
      problems trying to bump expo-modules-core to 0.6.0, with the
      hypothesis that some RN upgrade would fix that issue; see
        https://github.com/zulip/zulip-mobile/pull/5203#issuecomment-1020722398 .
      When we got to RN 0.67 and still saw the error, we found that
      Expo actually has a workaround (it papers over a RN problem),
      and we just have to take the Expo code with that:
        https://github.com/expo/expo/commit/c91d5a3e4#diff-53a846ea04b571c7981cbbab9b69d839993ff6f2982ad4a1a3fd02be5b042652R1-R36 .
      It's available in expo-modules-autolinking 0.4.0, and we get
      it with `expo` 44. I've updated
        https://github.com/zulip/zulip-mobile/pull/5203#issuecomment-1020722398
      with this information.
    - As mentioned in the changelog
        ( https://github.com/expo/expo/blob/main/packages/expo-screen-orientation/CHANGELOG.md#410--2021-12-03 )
      , the setup instructions have been simplified, so we make
      corresponding changes in ios/ZulipMobile/AppDelegate.m and
      ios/ZulipMobile/Info.plist. (Some of the changes in
      AppDelegate.m are unrelated. They're from a diff that we're
      asked to apply, in Expo's upgrade guide.)

  expo-web-browser: Major-version bump, but the only breaking change
    announced is dropping iOS 11 support, and we've done that:
      https://github.com/expo/expo/blob/main/packages/expo-web-browser/CHANGELOG.md

  react-native-gesture-handler:
    - v2 comes with a few announced breaking changes, but none
      should apply to us because we don't use the package directly
      ourselves:
        https://github.com/software-mansion/react-native-gesture-handler/releases/tag/2.0.0 .
      (We added it to satisfy peer-dep requirements for React
      Navigation. We don't get any peer-dep complaints from React
      Navigation when we do this upgrade.)
    - The Expo upgrade guide is apparently wrong in saying
        ( https://blog.expo.dev/expo-sdk-44-4c4b8306584a#d532 )
      that a requirement to use `<GestureHandlerRootView>` is new in
      v2; the v1 doc also mentions the requirement. For why we don't
      use `<GestureHandlerRootView>`, see the code comment we added
      in our 9c6009964.

  jest-expo: A major version bump, but things still seem to work
    fine, and the changelog doesn't start until 46.0.0? :shrug:
      https://github.com/expo/expo/blob/main/packages/jest-expo/CHANGELOG.md

Here are other updates it proposed, and why we aren't taking them:

  @react-native-async-storage/async-storage
    from ^1.13.0 to ~1.15.0,
    so we'd get 1.15.7 instead of 1.17.6
    (a downgrade; good to avoid if possible)

  @react-native-community/netinfo
    from 6.0.0 to 7.1.3,
    so we'd get 7.1.3 instead of 6.0.0
    (see e6d1231f7 for why we've pinned to 6.0.0 for now)

  expo-apple-authentication
    from ^4.0.0 to ~4.1.0,
    so we'd get 4.1.0 instead of 4.2.1
    (a downgrade; good to avoid if possible)

  expo-sqlite
    from ^10.0.0 to ~10.1.0,
    so we'd get 10.1.1 instead of 10.2.0
    (a downgrade; good to avoid if possible)

  react, react-native, and @types/react-native
    downward, so we'd get react-native 0.64.3 instead of 0.67.4
    (we definitely don't want that)

  react-native-reanimated
    from "^2.2.0 <2.3.0" to ~2.3.1
    so we'd get 2.3.3 instead of 2.2.4
    (We'd upper-bounded this because of an error we observed in
      2.3.0, which was reportedly caused by an incompatibility with
      Expo 43. There was hope at the time that it was fixed with
      Expo 44 --
        https://github.com/software-mansion/react-native-reanimated/issues/2702#issuecomment-988743559
      -- and that seems to be true; I don't see an error like that
      if I take this upgrade. However, "Debug JS Remotely" breaks
      with an insta-crash on startup, at least on Android. So if we
      need this upgrade, we should either debug that, or see if we
      agree with a finding that we should…abandon "Debug JS
      Remotely":
        https://github.com/software-mansion/react-native-reanimated/issues/1990#issuecomment-850564351 )

  react-native-safe-area-context
    from ^3.1.7 to 3.3.2,
    so we'd get 3.3.2 instead of 3.4.1
    (a downgrade; good to avoid if possible)

  react-native-screens
    from ^2.10.1 to ~3.10.1,
    so we'd get 3.10.2 instead of 2.18.1
    (we're managing this upgrade as part of upgrading React
      Navigation 6; good to not conflict with that if possible)

  react-native-webview
    from ^11.6.4 to 11.15.0,
    so we'd get 11.15.0 instead of 11.22.2
    (a downgrade; good to avoid if possible)

[gnprice]

I assume, all else being equal, it's better to put this in
devDependencies than install it globally, since we want commands to
have consistent results across environments. (The guide we're about
to follow, to upgrade to Expo 44, would have us install it
globally.)

Yeah, agreed.

It comes with a ton of new dependencies, though, and that
might be a reason to not have it in the project.

Hmm. It sure does make the yarn.lock a lot longer, which sounds like it's pulling in a lot of dependencies:

 yarn.lock    | Bin 560322 -> 768341 bytes

But it doesn't increase the total size of node_modules by nearly as much. Before:

$ git checkout main~~ && yarn
$ du -s -BMB node_modules/
1109MB	node_modules/

After:

$ git checkout main~ && yarn
$ du -s -BMB node_modules/
1220MB	node_modules/

So it's adding 111MB of new dependencies, which sounds big… except that we have 1109MB already, so it's only 10%. I think it makes sense to not try to optimize that when the cost would be version skew.

[gnprice]

All that reasoning for upgrades to take or not take makes sense. Thanks for the details!

However, "Debug JS Remotely" breaks
      with an insta-crash on startup, at least on Android. So if we
      need this upgrade, we should either debug that, or see if we
      agree with a finding that we should…abandon "Debug JS
      Remotely":
        https://github.com/software-mansion/react-native-reanimated/issues/1990#issuecomment-850564351 )

Hmm, yikes. Ultimately I do expect we'll be on Hermes, and so I guess Hermes Inspector as a result. But until then, we definitely need a way to get a JS debug console. Holding react-native-reanimated back seems like a good plan.

[chrisbobbe]

Thanks for the review!

Marking as a draft because I'd like to use tsflower for some of the dependencies I'm bumping here. 🙂

Just sent #5447 for this.

[chrisbobbe]

Revision pushed, and this one includes my current revision for #5449. It may be easier to settle that one first.

[chrisbobbe]

Just rebased, so this is ready for review. 🙂

[chrisbobbe]

Just rebased again, so this is ready for review. 🙂

[gnprice]

All looks good -- merging. Thanks for taking care of this upgrade!