Skip to content
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

Migrate to "Expo modules", from react-native-unimodules #5133

Closed
chrisbobbe opened this issue Nov 18, 2021 · 2 comments · Fixed by #5203
Closed

Migrate to "Expo modules", from react-native-unimodules #5133

chrisbobbe opened this issue Nov 18, 2021 · 2 comments · Fixed by #5203
Labels
dependencies Pull requests that update a dependency file

Comments

@chrisbobbe
Copy link
Contributor

chrisbobbe commented Nov 18, 2021

The react-native-unimodules package is deprecated as of SDK 43, and the module system and autolinking implementation now live in the expo package instead, starting with expo@43.0.0-beta.

https://blog.expo.dev/whats-new-in-expo-modules-infrastructure-7a7cdda81ebc

The migration guide is here.

We'll want to do the "manual configuration" step because we have nontrivial custom code in android/ and ios/ and can't just clear those out and run a command to replace them.

@chrisbobbe chrisbobbe added the dependencies Pull requests that update a dependency file label Nov 18, 2021
gnprice added a commit to gnprice/zulip-mobile that referenced this issue Dec 30, 2021
This isn't quite the latest version; for now we'll use v9.x in order
to stick with "unimodules".  Issue zulip#5133 is open for the migration
that'll let us advance to v10.x.

Include a libdef, generated with flowgen with small manual fixups
as described in comments.  The libdef is actually from a newer
version because that's what I tried first; I tried rerunning flowgen
on the older version, and the differences in the new one are pure
compatible improvements (cleaning up some type definitions; adding
comments; replacing `any[]` as the type for `args` on `executeSql`.)
chrisbobbe pushed a commit to gnprice/zulip-mobile that referenced this issue Jan 5, 2022
This isn't quite the latest version; for now we'll use v9.x in order
to stick with "unimodules".  Issue zulip#5133 is open for the migration
that'll let us advance to v10.x.

Include a libdef, generated with flowgen with small manual fixups
as described in comments.  The libdef is actually from a newer
version because that's what I tried first; I tried rerunning flowgen
on the older version, and the differences in the new one are pure
compatible improvements (cleaning up some type definitions; adding
comments; replacing `any[]` as the type for `args` on `executeSql`.)
gnprice added a commit that referenced this issue Jan 11, 2022
This isn't quite the latest version; for now we'll use v9.x in order
to stick with "unimodules".  Issue #5133 is open for the migration
that'll let us advance to v10.x.

Include a libdef, generated with flowgen with small manual fixups
as described in comments.  The libdef is actually from a newer
version because that's what I tried first; I tried rerunning flowgen
on the older version, and the differences in the new one are pure
compatible improvements (cleaning up some type definitions; adding
comments; replacing `any[]` as the type for `args` on `executeSql`.)
sumj25 pushed a commit to sumj25/zulip-mobile that referenced this issue Jan 12, 2022
This isn't quite the latest version; for now we'll use v9.x in order
to stick with "unimodules".  Issue zulip#5133 is open for the migration
that'll let us advance to v10.x.

Include a libdef, generated with flowgen with small manual fixups
as described in comments.  The libdef is actually from a newer
version because that's what I tried first; I tried rerunning flowgen
on the older version, and the differences in the new one are pure
compatible improvements (cleaning up some type definitions; adding
comments; replacing `any[]` as the type for `args` on `executeSql`.)
@chrisbobbe
Copy link
Contributor Author

chrisbobbe commented Jan 19, 2022

OK, I've poked around a bit, trying to understand the changes listed here with instructions to "apply" them to our project. Nothing there really helps us understand why these are the right changes to make, or exactly what'll happen if we make them.

My pretty good guess right now is that those diffs correspond to a subset of the changes in a "template app" maintained by Expo: the templates/expo-template-bare-minimum directory in https://github.com/expo/expo, between the sdk-42 branch and the sdk-43 branch, i.e.,

git diff upstream/sdk-42..upstream/sdk-43 -- templates/expo-template-bare-minimum

I wanted to know what commits led to those particular changes, from earliest to latest; here they are (it's not a huge list):

$ git log --oneline --reverse upstream/sdk-42..upstream/sdk-43 -- templates/expo-template-bare-minimum
63b5a92b8 [templates] Remove unnecessary imports
c44d9daa8 Remove READ_PHONE_STATE permission from default template (#13176)
15aa41994 Update AndroidManifest.xml (#13173)
79ca9839c [expo-constants] Modularized  expo-constants without further app setup (#13424)
b9f2132e7 Remove AppleTVOS12 JavaScriptCore.framework (#13591)
060fbd4fa Remove xib file (#13590)
3ad2d33e8 Added iOS background color support (#13607)
9e66f3bce [template] Add react-native-safe-area-context to expo-template-bare-minimum (#13840)
05f2ed0c7 [autolinking] Use NodeJS to resolve autolinking script location & popularise it among other imports (#13901)
f05c8ccb6 [android] Update Gradle to 6.9 (#13929)
896103abd [sdk] upgrade typescript to v4.3.5 (#14015)
507e608fd [ios][autolinking] Move autolinking scripts from the adapter to expo-modules-core (#14046)
d3f983699 [ios] fix autolink error from pod install (#14034)
dbd384b22 [template] React Native Image gif and webp support (#14163)
09e76aae3 [templates] Remove expo forked react-native from managed apps (#14261)
eb2c86e38 [ios] Fix versioning script and shell app workflows (#14436)
505f2066b [expo] Updates splash, adds dist/ to gitignore (#14439)
9781212eb [templates] Update templates for the next SDK (#14409)
9886c0aaf [expo-modules][ios] Fix errors from use_frameworks in Podfile (#14523)
38acbdec4 Update versions in project templates
d3b29ead0 [templates] Automatically resolve RN path in Xcode build scripts (#14546)
c152aa35c Update project templates to expo@43.0.0-beta.2
7ba6eeb78 [templates] Update for latest publish packages
f1812e55b [android] Added support for opening https links (#14638)
3bb65c866 [template] Use symbol to access reactNativePath rather than string (which does not work)
7946cd428 [template] Update bare template
8e1d7c05b [template] Set PROJECT_ROOT based on xcode project to fix release builds in monorepo
3de590bb7 [template] Update bare template
c026bda1d [templates] Publish updates for latest package versions
6e90b5214 [templates] Bump some dependencies
ffdcd2a62 [template] Use expo run commands in bare templates
d13d80c8f [template] Bump version for expo run changes
5b0c17a32 [templates] Update templates
3ab513775 [template] Add back updates manifest embed script
03ad7ee61 Revert "[template] Add back updates manifest embed script"
d034a6761 [react-native] Update from 0.64.2 -> 0.64.3 (#15108)
afa47a57b Update template versions
231fd1415 [templates] Publish
87a3d02aa [android] Fix building error from outside of project root (#15109)
c75c6c417 [template] Fix hermes command not found on monorepo (#15154)
2726b3298 [templates] Publish
282f5070b [templates] Add missing react test render and upgrade jest (#14993)
6877c1f5c [templates] Bump up expo-updates to 0.10.15 (#15257)

I think we can do basically what we've been doing for the last few React Native upgrades: study each of these commits to gather tasks we want to do on our own project (ignoring changes that are badly reasoned, reverted later, or just not relevant to our project), then do those tasks in our own disciplined way with well-ordered, clear, coherent commits.

I said above that the changes dumped into the migration guide are a subset of the diff I indicated…maybe we'll find out if some changes are intentionally omitted, and if we want to ignore them? The following files are touched in the diff but don't get mentioned in the migration guide:

  • templates/expo-template-bare-minimum/android/app/src/main/AndroidManifest.xml
  • templates/expo-template-bare-minimum/android/gradle/wrapper/gradle-wrapper.properties
  • templates/expo-template-bare-minimum/gitignore
  • templates/expo-template-bare-minimum/ios/HelloWorld/Base.lproj/LaunchScreen.xib
  • templates/expo-template-bare-minimum/yarn.lock
  • templates/expo-template-bare-minimum/ios/Podfile.lock

Our yarn.lock and ios/Podfile.lock (corresponding to the last two in that list) will be changed automatically when we run yarn after changing our package.json and/or ios/Podfile. We could check those automatic changes against what we see in this diff.

And the following files are mentioned, but in broad strokes that don't capture everything that appears in the diff:

  • templates/expo-template-bare-minimum/ios/HelloWorld.xcodeproj/project.pbxproj
  • templates/expo-template-bare-minimum/package.json

So we'll want to look into those more closely.

@chrisbobbe

This comment has been minimized.

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 25, 2022
Specifically, most of the changes to
templates/expo-template-bare-minimum in expo/expo@05f2ed0c7, and
relevant fixups from expo/expo@d3f983699, expo/expo@9781212eb, and
expo/expo/87a3d02aa. We also include this flavor of change as it
appears in expo/expo@9781212eb.

Might as well; shrug. See
  expo/expo#13901 (comment) .

expo/expo@05f2ed0c7 sloppily added a new import in the Podfile, even
though the commit was advertised as a pure refactor:

  require File.join(
    `node --print "require.resolve('@unimodules/react-native-adapter/package.json')"`,
    "../scripts/autolinking"
  )

We won't ever need that import, so we leave it out. It looks like
the relevant script was eventually moved to the `expo` package.
We'll import the script from there when we switch from "Unimodules"
to "Expo modules" (zulip#5133), which is the first time we'll need it.
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 25, 2022
Another change in the direction of the previous commit. Could take
it or leave it; shrug.

See the code comment for where we got this coherent lump of goo. I
don't like it, especially since this doesn't solve any problem we're
likely to encounter. Could just skip it? Anyway, I collected this
while gleaning Expo's commits for changes we *are* interested in
following, for zulip#5133.

It would be lovely if Expo would propose these kinds of fixes in
`react-native` itself. I think they realize that that'd be best, but
just haven't had time; see
  expo/expo#13901 (comment) :

> That's a good point that we should make that change in
> `react-native` as well, thanks for pointing that out 🙇
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 25, 2022
Like we did in 196a316.

Changelog:
  https://github.com/JetBrains/kotlin/blob/master/ChangeLog.md#1610

This seems to fix the following error we'd see on running

  `tools/test native --all-files`

after switching from Unimodules to Expo modules (zulip#5133):

```
e:
/Users/chrisbobbe/dev/zulip-mobile/node_modules/expo-sqlite/android/src/main/java/expo/modules/sqlite/SQLiteModule.kt:
(106, 55): Type inference failed: Not enough information to infer
parameter T in fun <reified T> arrayOfNulls(size: Int): Array<T?>
Please specify it explicitly.

FAILURE: Build failed with an exception.
```

Inspired to try this by
  expo/expo#15131 (comment) .
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 25, 2022
Done by mostly following the changes to Expo's
templates/expo-template-bare-minimum/ in expo/expo@9781212eb.

Expo's description of the new infrastructure is at
  https://blog.expo.dev/whats-new-in-expo-modules-infrastructure-7a7cdda81ebc .

They gave a migration guide that suggested making changes similar to
these, but which didn't end up helping us understand why they were
the right changes to make or what would happen if we made them. That
guide is at
  https://github.com/expo/fyi/blob/main/expo-modules-migration.md .

We've cleared up some of the mystery; see zulip#5133 and previous commits
in this series.

In this commit:

- (Mostly follow expo/expo@9781212eb, as mentioned)

- Also, upgrade all our `expo-*` direct dependencies so that they
  work with the new system. (We upgrade them minimally, to minimize
  having to think about possible unrelated breaking changes right
  now.) Details at
    zulip#5133 (comment) .

- Remove
  android/app/src/main/java/com/zulipmobile/generated/BasePackageList.java,
  since its only import was removed. (Expo didn't have this file in
  version control, and the migration guide didn't mention the file.)

- The Expo commit assumes that our project has done special setup
  for `expo-updates`, `expo-constants`, and `expo-splash-screen`. It
  makes changes to that setup, which we ignore since we don't use
  any of those. If we need them in the future, we'll just look up
  their current setup instructions at the time.

- Don't add an empty Swift file. The migration guide says, "A blank
  Swift file must be created for native modules with Swift files to
  work correctly." With `find node_modules | grep .swift` in our
  project, I see that expo-modules-core and expo-web-browser have
  many Swift files in them, and I don't have any problems building
  or running the app without an empty Swift file. The template app
  doesn't add one either.

- Don't add a Podfile.properties.json file. Like the changes in
  expo/expo@dbd384b22, this would have us put certain config values
  in some new Expo-branded variables. We're happy keeping them
  inline.

- Update our value for `transformIgnorePatterns` in the Jest config,
  following an error when running Jest.

Fixes: zulip#5133
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 25, 2022
Done by mostly following the changes to Expo's
templates/expo-template-bare-minimum/ in expo/expo@9781212eb.

Expo's description of the new infrastructure is at
  https://blog.expo.dev/whats-new-in-expo-modules-infrastructure-7a7cdda81ebc .

They gave a migration guide that suggested making changes similar to
these, but it didn't end up helping us understand why they were the
right changes to make or what would happen if we made them. That
guide is at
  https://github.com/expo/fyi/blob/main/expo-modules-migration.md .

We've cleared up some of the mystery; see
  zulip#5203 (comment)
and previous commits in this series.

In this commit:

- (Mostly follow expo/expo@9781212eb, as mentioned)

- Also, upgrade all our `expo-*` direct dependencies so that they
  work with the new system. (We upgrade them minimally, to minimize
  having to think about possible unrelated breaking changes right
  now.) Details at
    zulip#5203 (comment) .

- Remove
  android/app/src/main/java/com/zulipmobile/generated/BasePackageList.java,
  since its only import was removed. (Expo didn't have this file in
  version control, and the migration guide didn't mention the file.)

- The Expo commit assumes that our project has done special setup
  for `expo-updates`, `expo-constants`, and `expo-splash-screen`. It
  makes changes to that setup, which we ignore since we don't use
  any of those. If we need them in the future, we'll just look up
  their current setup instructions at the time.

- Don't add an empty Swift file. The migration guide says, "A blank
  Swift file must be created for native modules with Swift files to
  work correctly." With `find node_modules | grep .swift` in our
  project, I see that expo-modules-core and expo-web-browser have
  many Swift files in them, and I don't have any problems building
  or running the app without an empty Swift file. The template app
  doesn't add one either.

- Don't add a Podfile.properties.json file. Like the changes in
  expo/expo@dbd384b22, this would have us put certain config values
  in some new Expo-branded variables. We're happy keeping them
  inline.

- Update our value for `transformIgnorePatterns` in the Jest config,
  following an error when running Jest.

Fixes: zulip#5133
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 25, 2022
Done by mostly following the changes to Expo's
templates/expo-template-bare-minimum/ in expo/expo@9781212eb.

Expo's description of the new infrastructure is at
  https://blog.expo.dev/whats-new-in-expo-modules-infrastructure-7a7cdda81ebc .

They gave a migration guide that suggested making changes similar to
these, but it didn't end up helping us understand why they were the
right changes to make or what would happen if we made them. That
guide is at
  https://github.com/expo/fyi/blob/main/expo-modules-migration.md .

We've cleared up some of the mystery; see
  zulip#5203 (comment)
and previous commits in this series.

In this commit:

- (Mostly follow expo/expo@9781212eb, as mentioned)

- Also, upgrade all our `expo-*` direct dependencies so that they
  work with the new system. (We upgrade them minimally, to minimize
  having to think about possible unrelated breaking changes right
  now.) Details at
    zulip#5203 (comment) .

- Remove
  android/app/src/main/java/com/zulipmobile/generated/BasePackageList.java,
  since its only import was removed. (Expo didn't have this file in
  version control, and the migration guide didn't mention the file.)

- The Expo commit assumes that our project has done special setup
  for `expo-updates`, `expo-constants`, and `expo-splash-screen`. It
  makes changes to that setup, which we ignore since we don't use
  any of those. If we need them in the future, we'll just look up
  their current setup instructions at the time.

- Don't add an empty Swift file. The migration guide says, "A blank
  Swift file must be created for native modules with Swift files to
  work correctly." With `find node_modules | grep .swift` in our
  project, I see that expo-modules-core and expo-web-browser have
  many Swift files in them, and I don't have any problems building
  or running the app without an empty Swift file. The template app
  doesn't add one either.

- Don't add a Podfile.properties.json file. Like the changes in
  expo/expo@dbd384b22, this would have us put certain config values
  in some new Expo-branded variables. We're happy keeping them
  inline.

- Update our value for `transformIgnorePatterns` in the Jest config,
  following an error when running Jest.

- Some sub-dependency looks like it's changing the output of
  `generate-webview-js`. Examine that output (looks OK), and commit.

Fixes: zulip#5133
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 28, 2022
Like we did in 196a316.

Changelog:
  https://github.com/JetBrains/kotlin/blob/master/ChangeLog.md#1610

This seems to fix the following error we'd see on running

  `tools/test native --all-files`

after switching from Unimodules to Expo modules (zulip#5133):

```
e:
/Users/chrisbobbe/dev/zulip-mobile/node_modules/expo-sqlite/android/src/main/java/expo/modules/sqlite/SQLiteModule.kt:
(106, 55): Type inference failed: Not enough information to infer
parameter T in fun <reified T> arrayOfNulls(size: Int): Array<T?>
Please specify it explicitly.

FAILURE: Build failed with an exception.
```

Inspired to try this by
  expo/expo#15131 (comment) .
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 28, 2022
Done by mostly following the changes to Expo's
templates/expo-template-bare-minimum/ in expo/expo@9781212eb.

Expo's description of the new infrastructure is at
  https://blog.expo.dev/whats-new-in-expo-modules-infrastructure-7a7cdda81ebc .

They gave a migration guide that suggested making changes similar to
these, but it didn't end up helping us understand why they were the
right changes to make or what would happen if we made them. That
guide is at
  https://github.com/expo/fyi/blob/main/expo-modules-migration.md .

We've cleared up some of the mystery; see
  zulip#5203 (comment)
and previous commits in this series.

In this commit:

- (Mostly follow expo/expo@9781212eb, as mentioned)

- Also, upgrade all our `expo-*` direct dependencies so that they
  work with the new system. (We upgrade them minimally, to minimize
  having to think about possible unrelated breaking changes right
  now.) Details at
    zulip#5203 (comment) .

- Remove
  android/app/src/main/java/com/zulipmobile/generated/BasePackageList.java,
  since its only import was removed. (Expo didn't have this file in
  version control, and the migration guide didn't mention the file.)

- The Expo commit assumes that our project has done special setup
  for `expo-updates`, `expo-constants`, and `expo-splash-screen`. It
  makes changes to that setup, which we ignore since we don't use
  any of those. If we need them in the future, we'll just look up
  their current setup instructions at the time.

- Don't add an empty Swift file. The migration guide says, "A blank
  Swift file must be created for native modules with Swift files to
  work correctly." With `find node_modules | grep .swift` in our
  project, I see that expo-modules-core and expo-web-browser have
  many Swift files in them, and I don't have any problems building
  or running the app without an empty Swift file of our own. The
  template app doesn't add one either.

- Don't add a Podfile.properties.json file. Like the changes in
  expo/expo@dbd384b22, this would have us put certain config values
  in some new Expo-branded variables. We're happy keeping the values
  inline.

- Update our value for `transformIgnorePatterns` in the Jest config,
  following an error when running Jest.

- Looks like some sub-dependency at its updated version wants to
  cause different output for `generate-webview-js`. Examine that
  output (looks OK), and commit.

Fixes: zulip#5133
gnprice pushed a commit to chrisbobbe/zulip-mobile that referenced this issue Jan 28, 2022
Like we did in 196a316.

Changelog:
  https://github.com/JetBrains/kotlin/blob/master/ChangeLog.md#1610

This seems to fix the following error we'd see on running

  `tools/test native --all-files`

after switching from Unimodules to Expo modules (zulip#5133):

```
e:
/Users/chrisbobbe/dev/zulip-mobile/node_modules/expo-sqlite/android/src/main/java/expo/modules/sqlite/SQLiteModule.kt:
(106, 55): Type inference failed: Not enough information to infer
parameter T in fun <reified T> arrayOfNulls(size: Int): Array<T?>
Please specify it explicitly.

FAILURE: Build failed with an exception.
```

Inspired to try this by
  expo/expo#15131 (comment) .
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant