I tried upgrading to SDK 47, failed due to some other issues I’ll report later, and fell back to 46, but now I can no longer do expo publish as I could before:
$ expo publish
$ expo publish is not supported in the local CLI, please use eas update instead
I thought this was due to upgrading the global expo but I tried sudo npm install -g expo@46.0.7 (what my project is at) and that didn’t help.
So I tried switching to eas update and that ostensibly worked:
[...]
✔ Published!
However, my Expo Go client is still pointing at the old expo published build. I went to the URL reported by eas update, clicked on the Preview button next to Android, scanned it with my phone, and it immediately crashed. adb logcat shows:
11-11 16:22:43.004 17765 18669 E ReactNativeJS: TypeError: null is not an object (evaluating 'f.default.manifest.version')
11-11 16:22:43.013 17765 18669 I ReactNativeJS: Running "main
11-11 16:22:43.015 17765 18669 E ReactNativeJS: Invariant Violation: "main" has not been registered. This can happen if:
11-11 16:22:43.015 17765 18669 E ReactNativeJS: * Metro (the local dev server) is run from the wrong folder. Check if Metro is running, stop it and restart it in the current project.
11-11 16:22:43.015 17765 18669 E ReactNativeJS: * A module failed to load due to an error and `AppRegistry.registerComponent` wasn't called.
11-11 16:22:43.023 17765 18670 F libc : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x673906bb80 in tid 18670 (mqt_native_modu), pid 17765 (st.exp.exponent)
I would prefer to just get back to expo publish if possible.
There’s a difference between the expo package (that should be a dependency of your app and should not be installed globally) and expo-cli that should be installed globally and not as a dependency of your app.
First fix the above.
Then, if you want to continue with the classic OTA updates, use expo-cli publish to publish them. It might warn you to use npx expo instead, but you can ignore it for this use case. For things like start, install, etc., you should indeed use npx expo ....
(I also had to remove some stuff from app.config.js that was added during the eas update testing as otherwise I got, “It seems like your project is configured for EAS Update. Please use ‘eas update’ instead.”)
[…]
In the future, we plan to scale down Classic Updates as we transition to EAS Update. We will ensure every developer still using the service will have ample notice to upgrade to the modern Expo Updates format so that they can use another update service like their own servers or EAS Update.
@wodin Ok, makes sense. I’m fine to transition to EAS Update but I was confused with the experience (besides the crash). With Classic, I have a website, https://expo.dev/@findhumane/findhumane, that I went to for the QR code to scan. When I published a new version, I simply opened Expo Go, clicked on my recently used app link, and it would get the latest version.
Am I understanding correctly that, with EAS Update, I have to load the new, specific build link every time for each build?
Instead of Constants.manifest, use Constants.expoConfig, which is designed to be consistent in most scenarios between the old updates system and EAS Update, and between running embedded updates and remotely downloaded updates.
