0.71 Support #108
0.71 Support #108
Conversation
|
There seems to be some incompatibility between TypeORM and the babel version/preset used in 0.71... can't really tell at the moment what is going on, but if I comment the TypeORM tests the app transpiles and the tests run.
The solution is to open a ticket on the TypeORM and ask them to take a look but that could takes months to resolve |
|
A related issue: babel/babel#13742 |
|
Here is a full stack trace for the babel error: I've already tried de-duping but that does not seem to work |
|
I'm having a duplicate class error on android when I try to use the lib in a project that uses react-native-safe-area-context.
|
|
@ospfranco same duplicate class error with |
|
ok, so I just got confirmation that libraries will need to be updated and support only >= 0.71. So, I'm going to stop worrying about conflicts with the other sources and each one will have to be updated independently. |
|
I was able to get this working with this patch https://github.com/Expensify/App/blob/3e39b3fba33f8f23cbf744073fb3076c5468ce30/patches/react-native-quick-sqlite%2B7.0.0.patch. The duplicate class issue was caused by this line https://github.com/ospfranco/react-native-quick-sqlite/pull/108/files#diff-197b190e4a3512994d2cebed8aff5479ff88e136b8cc7a4b148ec9c3945bd65aR53. Removing it works. I was also able to simplify and remove some more code from build.gradle. Note that this is testing using old arch, I haven't tried with new arch enabled but I assume it should work fine. This is also not backwards compatible with <0.71. |
I also tried removing the |
|
I think the plugin is supposed to be used only for apps and not libraries, my guess is the duplicate classes are caused by codegen being ran twice. I checked reanimated which has 0.71 support and they dont use the plugin in their build.gradle. |
|
The react-native-mmkv library was facing the same issue and with this change mrousavy/react-native-mmkv#506 is building without errors. Applying the same to quick-sqlite also compiles without errors |
|
@ospfranco I'm still getting following error for 7.0.0, with RN 0.71.1. I have a question, is turning on new arch mandatory for RN 0.71? I thought it was optional. |
|
@panda0603 you need to use 7.0.0-beta0. And, I'm not sure yet if new arch is required, I copied the build.gradle from another project. |
|
A new version is out If fabric needs to be enabled I'm not 100% sure yet, I will try to remove it and see what happens (or you can patch-package yourself). |
I have the same exact issue with @panda0603. |
|
@only1chi sorry, no time to test, patch-package it yourself and see if it works. |
I was able to get a working |
|
@only1chi thanks for the gradle file, it indeed seems to work. It is published under 8.0.0-beta.2 and wait for feedback from other users |
Thank you! |
android/CMakeLists.txt
Outdated
| ReactAndroid::jsi | ||
| ReactAndroid::turbomodulejsijni | ||
| ReactAndroid::react_nativemodule_core | ||
| ReactAndroid::hermes_executor |
There was a problem hiding this comment.
@ospfranco this library is awesome, thanks for taking the time! From my initial tests SELECTs seem to be around 3-5x faster for 100k records vs all the bridge-based libraries. Bulk insert transactions might even be 8x faster in some cases.
I had an error getting the 8.0.0-beta.2 release working with a JSC-based app:
Error: Exception in HostFunction: java.lang.UnsatisfiedLinkError: dlopen failed: library "libhermes_executor.so" not found
I borrowed this idea from expo-modules-core but think it could be fixed by doing something like:
if(${USE_HERMES})
set(JSEXECUTOR_LIB ReactAndroid::hermes_executor)
else()
set(JSEXECUTOR_LIB ReactAndroid::jscexecutor)
endif()
target_link_libraries(
${PACKAGE_NAME}
${LOG_LIB}
fbjni::fbjni
ReactAndroid::jsi
ReactAndroid::turbomodulejsijni
ReactAndroid::react_nativemodule_core
${JSEXECUTOR_LIB}
android
)
|
@mjmasn thanks a lot, that works. A new version is published under |
|
Thanks for your effort! |
WIP, currently the android build config is valid but header file for the CallInvoker is missing and therefore compilation fails
Takes care of #107