Android and iOS builds on EAS broken, but legacy work fine

Hey, I recently signed up for the EAS build and cannot build for iOS or Android. The legacy builds work fine.

For my Android build it is failing on:

Task :app:bundleReleaseJsAndAssets
Error: The resource `/build/workingdir/build/index.js` was not found.

For my iOS build it is failing on:

❌  error: File /Users/expo/Library/Developer/Xcode/DerivedData/xxxx/Build/Intermediates.noindex/ArchiveIntermediates/xxxx/BuildProductsPath/Release-iphoneos/xxxx.app/main.jsbundle does not exist. This must be a bug with


❌ Metro encountered an error:
Error loading Metro config and Expo app config: Expected `fromDir` to be of type `string`, got `undefined`

Here is the error details from the xcode logs:

error: File /Users/expo/Library/Developer/Xcode/DerivedData/HabitStar-eijmukzmubkgsxegvbjmzjshewkb/Build/Intermediates.noindex/ArchiveIntermediates/HabitStar/BuildProductsPath/Release-iphoneos/habitstar.app/main.jsbundle does not exist. This must be a bug with
+ echo 'React Native, please report it here: https://github.com/facebook/react-native/issues'
React Native, please report it here: https://github.com/facebook/react-native/issues
+ exit 2
Error: @build-script-error-begin
Error loading Metro config and Expo app config: Expected `fromDir` to be of type `string`, got `undefined`
Make sure your project is configured properly and your app.json / app.config.js is valid.
If you are using environment variables in app.config.js, verify that you have set them in your EAS Build profile configuration or secrets.
@build-script-error-end
    at /Users/expo/workingdir/build/node_modules/expo-updates/scripts/createManifest.js:32:11
GenerateDSYMFile /Users/expo/Library/Developer/Xcode/DerivedData/HabitStar-eijmukzmubkgsxegvbjmzjshewkb/Build/Intermediates.noindex/ArchiveIntermediates/HabitStar/BuildProductsPath/Release-iphoneos/habitstar.app.dSYM /Users/expo/Library/Developer/Xcode/DerivedData/HabitStar-eijmukzmubkgsxegvbjmzjshewkb/Build/Intermediates.noindex/ArchiveIntermediates/HabitStar/InstallationBuildProductsLocation/Applications/habitstar.app/habitstar (in target 'HabitStar' from project 'HabitStar')
    cd /Users/expo/workingdir/build/ios
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil /Users/expo/Library/Developer/Xcode/DerivedData/HabitStar-eijmukzmubkgsxegvbjmzjshewkb/Build/Intermediates.noindex/ArchiveIntermediates/HabitStar/InstallationBuildProductsLocation/Applications/habitstar.app/habitstar -o /Users/expo/Library/Developer/Xcode/DerivedData/HabitStar-eijmukzmubkgsxegvbjmzjshewkb/Build/Intermediates.noindex/ArchiveIntermediates/HabitStar/BuildProductsPath/Release-iphoneos/habitstar.app.dSYM
/Users/expo/workingdir/build/ios/Pods/Pods.xcodeproj: warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.5.99. (in target 'boost-for-react-native' from project 'Pods')

I’m using the managed expo workflow. I believe I followed all the instructions per: EAS Build - Expo Documentation

What other info can I provide to help diagnose?

Do I need to have a metro.config.js file?

Failed Android Build: Build Details — 8a0b3c64-d928-4cfd-aed0-586c91eccf36 — habit-star — Expo

Failed iOS Build: Build Details — 8a0b3c64-d928-4cfd-aed0-586c91eccf36 — habit-star — Expo

are you using a monorepo? do you have a custom "main" in your package.json?

did you follow these migration instructions?

Thank you for the quick response.

  • Not a monorepo
  • I do have "main": "src/App.js", in my package.json. Would that be causing this potentially?

I did go through the migration instructions. Although, I do not have a metro.config.js and am wondering if that is now required per the instructions here?

yeah this could be causing the problem. there is currently a quirk with the build process where if you run expo prebuild in a project with a custom "main" we don’t modify it, but react-native’s built in bundle command (which is used when building on EAS Build currently) doesn’t support custom main files.

to solve this, create an index.js that looks like this, modify it to point to your main App file, make sure your App file exports the root component, then delete your "main" field in package.json. that will continue to work fine locally (we fallback to index.js if it exists and there is no main) and will also work on EAS Build. we’re working an expo bundle command that ensures we have consistent behavior when running in Expo Go and on EAS Build in these circumstances, but it’s not ready yet.

you can also debug this locally if you have Xcode / Android Studio installed - expo run:ios and expo run:android. be sure to clean up any files generated while debugging once you’re done

Awesome, i’m going to try this as soon as I can. Thank you so much!

@sturdynut did you perhaps start this app on a fairly old Expo SDK version?

If you create a new Managed app with expo init, you will see that main is defined as follows:

"main": "node_modules/expo/AppEntry.js"

And AppEntry.js contains:

import registerRootComponent from 'expo/build/launch/registerRootComponent';

import App from '../../App';

registerRootComponent(App);

So I think what Brent is saying is that if your main points directly at App.js (or is otherwise not pointing at AppEntry.js) then prebuild doesn’t handle that correctly.

@wodin - I can’t remember what version I started on, but it was before that was added! I am trying the builds again with the main entry pointing at node_modules/expo/AppEntry.js. Thank you! I’ll report back once I see how the builds do.

@wodin / @brents : Thank you both for the help! I was able to get both iOS and Android to build by the following:

  • Setting in package.json: "main": "node_modules/expo/AppEntry.js",
  • Updating my App.js to be at the root

I really appreciate the assistance, not sure I would have thought to do that. :raised_hands:t3:

1 Like

Sometimes I find it useful to create a new blank app and compare all the config etc. to the real app.

That is a great call and I will be doing that going forward. Very much appreciate the help again!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.