Repository navigation
Roadmap for react-native-worklets 0.12 / Reanimated 4.6 support in Expo SDK 57+ #49224
Replies: 1 comment
|
Hi @miguelartazos! Thank you for providing such a clear breakdown and step-by-step reproduction details. The issue you're hitting is due to internal API breaking changes in react-native-worklets 0.12.x, specifically regarding native execution methods on C++ runtimes (WorkletRuntime::executeSync). Because expo-modules-core (v57.0.12) relies on this method inside WorkletJSCallInvoker.cpp for its worklet adapter bindings on Android, CMake compilation fails when linked against Worklets 0.12+. Here are answers to your questions and options to unblock your workflow: Answers to Your Questions Yes, compatibility updates for underlying JSI libraries like Worklets and Reanimated are typically handled via patch updates to expo-modules-core or canary releases. Given that Reanimated 4.6 enforces react-native-worklets 0.12, an expo-modules-core patch update will be necessary. What is the approved migration from WorkletRuntime::executeSync? In react-native-worklets 0.12, execution dispatch methods were refactored to align with updated thread-guard safety models. Calls to workletRuntime->executeSync(...) should be migrated to workletRuntime->runGuarded(...) or the designated schedule API depending on thread-context checks. Would the Expo team accept a focused PR updating this adapter? Yes! Community PRs updating expo-modules-core adapters for upstream JSI releases are highly encouraged. A PR updating expo-modules-core/android/src/main/cpp/worklets/WorkletJSCallInvoker.cpp (and checking equivalent iOS implementation, if applicable) would accelerate compatibility for SDK 57 users. Are other Expo Modules APIs affected? Worklet interaction within Expo is primarily encapsulated inside expo-modules-core. However, modules that register frame processors or JSI worklet listeners (such as expo-camera or expo-video) should also be tested to verify that no direct C++/JSI Worklet dependencies break during clean release builds. Recommended Immediate Steps JSON Update node_modules/expo-modules-core/android/src/main/cpp/worklets/WorkletJSCallInvoker.cpp to replace executeSync(...) with the new 0.12 C++ execution handle. Run npx patch-package expo-modules-core. Re-run ./gradlew :app:assembleRelease. |
Uh oh!
There was an error while loading. Please reload this page.
We tested upgrading a production Expo application with the following environment:
expo57.0.15)expo-modules-core: 57.0.12react-native-reanimated: 4.5.3 → 4.6.0react-native-worklets: 0.10.2 → 0.12.1Reanimated 4.6 supports React Native 0.86 and requires Worklets 0.12.x.
The iOS native build compiled successfully. Runtime compatibility was not treated as verified, however, because a clean Android release build failed while compiling
expo-modules-core:The command used was equivalent to:
cd android ./gradlew :app:clean :app:assembleRelease \ -PguinoteVersionCode=139 \ --no-daemonBefore rebuilding, we removed generated CMake state for the application,
expo-modules-core, Reanimated, Worklets, and other JSI dependencies to rule out stale native build artifacts.Our current understanding is:
WorkletRuntime::executeSync.expo-modules-core57.0.12 still relies on that API on Android.expo-modules-core57.0.12.We restored Reanimated 4.5.3 and Worklets 0.10.2, after which the existing Expo integration remained valid.
Could the Expo team clarify the following?
WorkletRuntime::executeSyncinside Expo Modules Core?We would be happy to prepare a minimal reproduction if this dependency combination is expected to work.
Thank you!
All reactions