expo: EAS does not build Expo SDK v44 Managed App
Summary
The following error is thrown on EAS build servers when trying to build an app that worked on Expo SDK v43 with no code changes other than expo upgrade
to v44.
› Compiling expo-localization Pods/ExpoLocalization » LocalizationModule.swift
❌ (node_modules/expo-localization/ios/LocalizationModule.swift:14:5)
12 | }
13 |
> 14 | function("getLocalizationAsync") {
| ^ cannot find 'function' in scope
15 | return Self.getCurrentLocalization()
16 | }
17 | }
▸ ** ARCHIVE FAILED **
▸ The following build commands failed:
▸ CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler (in target 'ExpoLocalization' from project 'Pods')
▸ CompileSwift normal arm64 /Users/expo/workingdir/build/node_modules/expo-localization/ios/LocalizationModule.swift (in target 'ExpoLocalization' from project 'Pods')
▸ CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler (in target 'ExpoLinearGradient' from project 'Pods')
▸ (3 failures)
** ARCHIVE FAILED **
CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler (in target 'ExpoLocalization' from project 'Pods')
CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler (in target 'ExpoLinearGradient' from project 'Pods')
CompileSwift normal arm64 /Users/expo/workingdir/build/node_modules/expo-localization/ios/LocalizationModule.swift (in target 'ExpoLocalization' from project 'Pods')
The following build commands failed:
(3 failures)
Exit status: 65
+-------------+-------------------------+
| Build environment |
+-------------+-------------------------+
| xcode_path | /Applications/Xcode.app |
| gym_version | 2.185.1 |
| sdk | iPhoneOS15.0.sdk |
+-------------+-------------------------+
Managed or bare workflow? If you have ios/
or android/
directories in your project, the answer is bare!
managed
What platform(s) does this occur on?
iOS
SDK Version (managed workflow only)
44
Environment
Expo CLI 5.0.3 environment info:
System:
OS: macOS 12.1
Shell: 5.8 - /bin/zsh
Binaries:
Node: 17.2.0 - ~/.nvm/versions/node/v17.2.0/bin/node
Yarn: 1.22.15 - ~/.nvm/versions/node/v17.2.0/bin/yarn
npm: 8.1.4 - ~/.nvm/versions/node/v17.2.0/bin/npm
SDKs:
iOS SDK:
Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
IDEs:
Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
npmPackages:
expo: ^44.0.0 => 44.0.0
react: 17.0.1 => 17.0.1
react-dom: 17.0.1 => 17.0.1
react-native: 0.64.3 => 0.64.3
npmGlobalPackages:
eas-cli: 0.42.4
expo-cli: 5.0.3
Expo Workflow: managed
Reproducible demo
https://expo.dev/accounts/careswitch/projects/careswitch/builds/69e426f5-c071-40cc-bfec-fa5e58aadccc
I’m not sure how to share something reproducible here since expo r
works just fine and the app loads normally on the Expo Go dev client. The issue is encountered solely when doing eas build
during the step that builds the expo-localization
native package.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 24 (13 by maintainers)
it looks like from your build that you have
@unimodules/core
installed. you should find where that is coming from and remove it. react-native-unimodules and its dependent packages are no longer used in sdk43+@bugsnag/expo
doesn’t directly depend on the modules core so I think it should be@bugsnag/expo/**/expo-modules-core
but I’d feel more confident withYes, that’s it! As a temporary workaround you can use yarn resolutions to enforce using version
^0.6.3
ofexpo-modules-core
or^13.0.0
ofexpo-constants
. I need to think a bit more what would be the best solution for bugsnag so we don’t hit such issues in the future 🤔In my case removing @bugsnag/expo module helped me
thanks for the follow up! we need to add some validation to
expo doctor
for thisI confirm that the newest version of
expo-localization
is not compatible with SDK43 and olders. We always recommend to useexpo install
command that ensures you have the right versions 😉@brentvatne Brilliant, that appeared to be the issue, appreciate that insight a lot! Appeared to work just fine in Expo SDK v43, v44 not so much, and didn’t catch it in the v44 blog post, but found another blog post that did call out this change unrelated to the v44 release.