-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🌊 Add Expo managed workflow support for SDK 39+ #13
🌊 Add Expo managed workflow support for SDK 39+ #13
Conversation
Also fixes uuidjs/uuid#375 |
@LinusU - any feedback on this? |
8e25a1a
to
85f4839
Compare
Hey @brentvatne, sorry for the delay on this, things have been a bit hectic lately. I amended some small changes:
I also tired to test this myself, but as SDK 39 isn't out yet I wasn't able to 😅 Anyhow, I get the proper error message on Expo so it's at least reading the correct file, I guess it will work when SDK 39 is out 🚀 Thank you for this and all your work on Expo! ❤️ |
Released in 🚢 1.5.0 / 2020-09-03 |
thanks @LinusU! |
Thanks to LinusU/react-native-get-random-values#13 Expo finally has support for a sync CSPRNG. Fixes #375
Hey, This PR broke apps using an ejected expo with an SDK older than 39.0.0. :( |
@tasn - it sounds like something is wrong with your app configuration. |
I have an ejected SDK 36 app with Typescript and I haven't messed with the metro config. How far back to .expo.js fix go for? No worries for me btw, I just help back the update, just wanted to let you know. |
@tasn - ah, are you using expokit? that could be the reason.. we don't support expokit anymore (as of sdk 38) so we can't guarantee that new things we do will be compatible with it. https://blog.expo.io/time-to-start-using-expos-bare-workflow-expokit-now-deprecated-d6052890c18b |
I am, yeah. I understand you don't support expokit anymore, and I've been meaning to upgrade. It's just a massive pain, so I haven't found the time yet. However, this library is not part of expo. Is there a way to maybe make it not break for expokit? |
@tasn - you could install expo-random and that would solve your problem. otherwise there isn't much we can do in the context of expokit, i think your solution of just reverting to 1.4.0 is good for now and when you have time to migrate away from expokit you can upgrade this as well |
@brentvatne I'm guessing that the answer is no, but is there any tricky work around that we could do here in the package? No |
@LinusU - unfortunately no, expokit doesn't have a special extension, so we couldn't do this at the module resolution level. there may be some properties we could inspect at runtime to choose the appropriate behavior, but i think it's not worth adding the complexity to support it. |
BTW I just verified that this now indeed works as desired with Expo SDK 39 🎉 ! See https://github.com/ctavan/uuid-example-expo |
Thanks to LinusU/react-native-get-random-values#13 Expo finally has support for a sync CSPRNG. Fixes #375
Thanks to LinusU/react-native-get-random-values#13 Expo finally has support for a sync CSPRNG. See also: https://dev.to/expo/expo-sdk-39-is-now-available-1lm8#new-synchronous-method-in-raw-exporandom-endraw- Fixes #375
Thanks to LinusU/react-native-get-random-values#13 Expo finally has support for a sync CSPRNG. See also: https://dev.to/expo/expo-sdk-39-is-now-available-1lm8#new-synchronous-method-in-raw-exporandom-endraw- Fixes #375
This is done by using the ExpoRandom native module when running in the Expo managed workflow, if it exists.
This does not add any overhead to apps that are not running in the Expo managed workflow. The
.expo.js
file is not included in the bundle.Fixes expo/expo#7209