I am currently using Expo SDK 32 with managed workflow. There’s a bug that has been addressed in the latest Expo source code and I am wondering if it’s at all possible for me to get that fix before next version is rolled out (which I have no idea if it’s going to be 6 months or 2 weeks)? I haven’t seen any nightly builds generated for Expo SDK, is there any?
I am new to Expo and want to check if it’s possible to use latest code? I was thinking if I eject my app and locally build Expo SDK, would that work?
1 Like
Would appreciate if someone from Expo team could provide some guidance here. Thanks!
same here!! urgently need to upgrade. The bug issue is already merged. At the time 33.0 is out, all my current user would have been gone by that time. And hopefully 33.0 wont bring another bug causing the another problem…It never end.
For the picture May 8 is the time I upgrade to 32.0. Now I am trapped to die
What bugs are these? Maybe some of us could suggest workarounds. The Managed Workflow doesn’t support users cherry-picking commits to native code. It can only ship native bits that are in an official SDK release.
Thanks for responding. Sounds like we could use latest code if we eject our app? Could you provide some guidance on that workflow? Does Expo team publish it’s release schedule? I don’t know when the next SDK is going to be released, knowing dates would help make informed decision about whether to wait for new SDK or eject app and go for bare workflow.
I have no insider information. Expo team puts their latest updates on blog.expo.io. You can read how to do bare workflow and ExpoKit on docs.expo.io. Bare workflow in theory would have more support for the latest version of React Native (since you just pick the libraries you want). Unless you’re talking about a very specific, isolated bugfix, I imagine it would be quite difficult to cherry-pick with ExpoKit. the Expo SDK and React Native version are just too tightly coupled there.
Again, if you want to describe the bug you’re trying to workaround, some of us may be able to help you workaround it without going to these lengths. A lot of us have SDK 32 apps on the app stores that working just fine.
The bug has been reported, fixed and merged by sjchmiela into expo-file-system version 5.0.0 10 days ago. (issue #4260, #4239,#4264). while expo SDK still shipping with 4.0.0…
Anyway, the issue is fixed as I switched to react-native-unimodule yesterday. Here are the solutions for those who get trapped:
I didn’t do an eject as I am sure it will be a big mess for a big project. I started with bare-minimum, make sure it work first, then add package and my components one by one. by using react-native-unimodule, I am able to cherry pick the module that I need.
Solution 1
At first, I find that I can directly edit the JAVA code into the .jar source files inside expo-file-system, which is inside node_modules) then build a release version of ur app before it get overwritten ( it sometime will be overwritten by e.g gradlew ./clean)
Solution 2
Then I find in the gradle.groove, if a package is specified with a higher version than the one inside react-native-unimodule (assume it is interfaced in unimodule) in the package.json, it will load the higher version one. So I added expo-file-system:5.0.0 in package.json together with unimodule (it included expo-file-system 4.0.0)
Solution 3
Afterward I find another solution, in package.json, do this :
expo-file-system:“https://github.com/expo/expo/packages/expo-file-system/5.0.0.tar.gz”
so in case it got merged but not yet uploaded to npm.
what if it not even merged but u need the fix badly. Fork it ! and then put it like.
expo-file-system:“https://github.com/your-github-account/expo/packages/expo-file-system/5.0.0.tar.gz”
After all, all solution works only when you rebuild your project without expo SDK, then you find their new react-native-unimodule is amazing. You wont’ play with spaghetti, again. Wait for SDK 33 to fix expo-file-system, what if other critical bug in expo-camera introduced in it? wait for SDK 34? It simply too big to get everything right in one particular moment. U pull one end of the spaghetti and find another side shortened. react-native-unimodule is ur life savior in short.
Good call. Yeah, when the issue is something with an extra library within the SDK (I was thinking maybe it was something in React Native itself), then the best route is getting out of the managed workflow and pulling in a different library. Way easier than trying to cherry-pick fixes. Even if you need ExpoKit, there’s often the option of using a non-Expo library with similar functionality (e.g., GitHub - itinance/react-native-fs: Native filesystem access for react-native does a lot of the same things).
@llamaluvr - For me the issue is fixed with this PR - Use proper context in AdMob. by mczernek · Pull Request #4099 · expo/expo · GitHub
I am not sure if ejecting would help in my case. Thanks.
If your issue is resolved by a non-Expo Admob library, like GitHub - sbugert/react-native-admob: A react-native component for Google AdMob banners, then ejecting would almost certainly help. I couldn’t quite tell the relationship between Expo’s admob and this one (or any others), but a lot of Expo SDK stuff is actually ports of other React Native libraries that are more-or-less bundled into Expo so you don’t have to install them. But with bare or ExpoKit, you have the option to install those.
oop sorry, my typo mistake, what I mean is expo-file-system itself, not react-file-system, there is no such thing. I updated my article.
