Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
deps: Upgrade
react-native-device-info to 6.0.2, the latest.
This is such a big leap between versions that my approach is to just tear down the package and set it up again, all in the same commit. This actually went very smoothly, for a few reasons: - We use a very small part of its API, especially after 18c37ce. - At least in the part we use, the library's own Flow types seem to be up-to-date. (We could have switched entirely to `expo-device`, and we could still do that, except that Expo has abandoned Flow completely, in favor of TypeScript. React Native Community has much better Flow support, generally.) - Since the addition of this package, we started using CocoaPods (33f4b41) and autolinking (a9a9ac7), which make it much easier to manage dependencies that use native code. In this commit: - Look over past commits and the installation instructions for v0.21.5 of this package [1] to see what we need to tear down: - Remove workaround code from 44a7e07; the problem was solved in react-native-device-info/react-native-device-info@95887635, released in v2.1.2. - Keep mock of this library from 8300c9f; experimentally, it's still necessary. - (Nothing else stands out.) - Upgrade version range of react-native-device-info from ^0.21.5 to ^6.0.2. - Skip some manual setup instructions labeled "AndroidX Support" [2] that say to add things in the `ext` block in `android/build.gradle`. - One chunk of these instructions says it's meant for supporting `deviceId` (it probably means `getDeviceId`), with a menu of different choices for that based on what modern new features we want to use. Probably best to make that choice if and when we actually decide to use `getDeviceId`. - Another chunk is labeled "include as needed". It suggests `compileSdkVersion` and `targetSdkVersion` be at least 28, in order to use AndroidX; ours are already. There are a few things there I don't quite understand, but we've been doing fine with AndroidX since we started using it in e433197, and presumably "as needed" implies we would know (or soon find out) if we needed that stuff. - Adjust our runtime code, if necessary (it's not necessary): - The two methods we do use, `getSystemName` and `getSystemVersion`, are still documented [3] [4] with the same usage as before. The changelog [5] doesn't suggest anything about these two methods, except for a blip with `getSystemName` where it had been returning "unknown" near-universally for one or two release candidates of v3, before that was promptly fixed. Manual testing on one physical Android device and one physical iOS device suggests that the same strings are given by those methods before and after the upgrade. (Also, notably, no build failures or runtime errors were observed.) In that experiment, the exported constant in src/utils/userAgent.js was: Before: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" After: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" If, one day, we're surprised by some unexpected string being used, we can dig into the implementation difference between v0.21.5 and v6.0.2 of this library and see what changed. [1] https://github.com/react-native-community/react-native-device-info/tree/v0.21.5#installation [2] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#androidx-support [3] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemname [4] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemversion [5] https://github.com/react-native-community/react-native-device-info/blob/v6.0.2/CHANGELOG.md Fixes: zulip#4240
- Loading branch information
1 parent
9cd4ceb
commit ff253df