TypeError: (0,o.default) is not a function

[wodin]

@jumptech

This allowed me to iterate round the recent package changes we’d made and eventually I found a combination that worked.

Great!

@jumptech

So can I just check I’ve understood correctly?

I believe you have it right, but I haven’t actually played around with OTA updates with an app built with EAS Build yet.

See here for an explanation of some of this stuff by one of the Expo team members:

What is the relationship between releaseChannel and channel in eas.json?

So you’re all set up correctly for EAS Update! However, it looks like you are calling Constants.manifest.extra somewhere (from expo-constants), but since Constants.manifest is null, you’re getting a fatal error when calling .extra on null. This guide instructs you to remove Constants.manifest.extra. If you’re using Constants.manifest.extra to access environment variables, we have a workaround for the time being here: https://docs.expo.dev/eas-update/environment-variables/#creating-an-envts-file…

I believe the following comment means “you can host it yourself”. Not that you can e.g. use the expo-updates with Microsoft CodePush or something like that:

expo-updates is a library that can be used with any update service

In terms of what you can/can’t update using OTA updates, see the Runtime versions and updates link that @sharpkel’s linked to in the above post.

@jumptech

And you don’t need to rebuild the app using eas unless or until, the SDK changes or you want to use a new package?

Basically, yes, but also certain other stuff from app.json like the icon etc.

@jumptech

Does that apply to all packages in package.json, or only those with a native element to them?

Only the ones with native code, but that also includes packages included with the Expo SDK. EAS Build does not include e.g. the Face detector or the Facebook API if you do not use them. So if you want to add those later you are going to need to rebuild.

EDIT: So if you know you’re going to use something later you can add it as a dependency, but not use it in the JS code. I think of this as building your own SDK. Then later you can add it to your JS and do an OTA update without having to rebuild. (But this is possibly only really useful during development/testing because the App/Play store will probably not like you to add new functionality over the air.)

If you have several similar apps you should be able to build a dev client with all of the dependencies used by all of the apps and use it for developing all of them like you might use Expo Go.