Add the appropriate “Tag” based on what Expo library you have a question on.
I have been using an EAS Build + managed workflow. However, when I install packages that are supported by Expo “out of the box”, there are local compilation errors, until I run an EAS build. This is using SDK 48, and I didn’t run into this issue at my last job using SDK 46.
I was under the impression that I would only need to run an EAS build when installing packages that aren’t supported by Expo when native modules are being impacted.
In this case today, with the expo-image-picker, when invoking the method as shown in the example docs, it results in an error:
TypeError: Cannot read property ‘launchImageLibraryAsync’ of undefined
so I restarted the server and it threw an error:
The native view manager required by name (ExpoImage) from NativeViewManagerAdapter isn’t exported by expo-modules-core
This implies to me that the package isn’t installed on my local app image, so I run the eas:build command and all issues are cleared up.
Can you please advise, is it to be expected that all dependencies are to be installed via EAS build now, even if they appear to be supported out of the box?
Basically, with the classic build system, all managed Expo apps would include the entire Expo SDK, whether you used it or not. This caused some big problems:
The app included a bunch of large code/assets that it probably didn’t use (e.g. the face detector). App size was one of the biggest complaints against Expo.
The app included code to track users for advertising purposes. Even if your app did not call that code it could cause problems for getting through the app review process.
With the new EAS Build build system, it only includes what you specify in your dependencies in package.json. This fixes the above issues, but unfortunately means that if you install another dependency that includes native code, you will need to create a new build of the app. Even if the dependency is part of the Expo SDK.
Of course, if you are able to use Expo Go for development, then you won’t have this problem there, but will still run into it when creating a preview/production build.
One thing you could do to reduce this issue is try to anticipate all of the dependencies you are likely to need for the next while and install all of those dependencies up front, even if you don’t call them from the JavaScript code.