Closed roryabraham closed 4 days ago
Hey, I would like to work on this issue!
@MrRefactor I'd strongly recommend you to try https://github.com/infinitered/flame. There's a talk from Jamon it's creator here. I hope it will help streamline the upgrade process for you.
@roryabraham Sure! I will get gpt-4 and try upgrading with that tool!
wrote some best practices on RN upgrades earlier today:
Update:
Update:
react-native-live-markdown
on androidCC: @roryabraham @mountiny
Update:
Created an issue in react-native-quick-sqlite as the same error is visible while building with fresh rn app. In meantime working on a fix for that problem.
Created an https://github.com/margelo/react-native-quick-sqlite/issues/37 in react-native-quick-sqlite as the same error is visible while building with fresh rn app. In meantime working on a fix for that problem.
Update:
Created an issue in @expensify/react-native-live-markdown
as the same error is visible while building with fresh rn app for android.
Update:
@MrRefactor The fix for @expensify/react-native-live-markdown
is pretty simple, it's just a matter of changing a single import in MarkdownUtils.java
:
-import com.facebook.react.views.text.CustomLineHeightSpan;
+import com.facebook.react.views.text.internal.span.CustomLineHeightSpan;
@tomekzaw Thanks Tomek!
Update: Implemented workarounds for:
@expensify/react-native-live-markdown
react-native-quick-sqlite
Working on new issues connected with:
Android:
lottie-react-native
expo
, expo-modules-core
,iOS
expo-modules-core
I will also create issue & pr in @react-native-async-storage/async-storage
as its showing warnings with mismatched versions of ksp
version
Also there was a question from @cead22 if we could upgrade rn to 0.73.5 in meantime as its fixing this issue
CC: @mountiny @roryabraham
commented in slack, but I think we should press on with the 0.74 upgrade
@MrRefactor, let's start doing updates in slack to get more visibility, then just link to the slack updates here in GH.
How can we help push this along? What are you doing to parallelize the work here? Can we get more people involved to split up the work?
@MrRefactor looking forward to seeing an update from you on this project.
Update on upgrade work: https://expensify.slack.com/archives/C01GTK53T8Q/p1711111014179099
CC: @roryabraham @mountiny
@roryabraham, I'm happy to help if a C+ is needed here.
latest discussion: https://expensify.slack.com/archives/C01GTK53T8Q/p1711111014179099
Update:
I will also post an update on slack - sorry for late update, needed to get back to speed after Easter.
@MrRefactor do you have an estimate when this PR will be ready for review?
@MrRefactor do you have an estimate when this PR will be ready for review?
Aiming at end of this week!
We got another Fabric related issue for which I proposed a patch:
Discussing it on Slack ๐งต, this RN v0.74 commit came up:
Which might fix our issue and the patch won't be required once we're on v0.74. We're currently debating whether to add the proposed patch or HOLD until we're upgraded.
I'm wondering if this issue may also have been fixed in RN 0.74
Update - 19.04:
Draft PR link -> link
After merging new arch to main, I needed to revert most of the changes as those have been resolved in new arch pr. Also as we are adding a bridgeless for new architecture it may require more effort as we estimated at the beginning.
There is one breaking issue connected to NotificationService target on iOS - /App/ios/NotificationServiceExtension/NotificationService.swift:8:8 Compiling for iOS 13.0, but module 'AirshipServiceExtension' has a minimum deployment target of iOS 14.0
I have messaged @arosiclair as he created that target couple of months ago. When we switch to higher deployment target its crashing with implementation issues:
Expo update: today expo released its first beta version of SDK51 for react-native 0.74.0 - link After updating all expo libraries it seems all building issues connected to expo are resolved on android side, for iOS need to resolve NotificationService issue first to make sure its working fine.
I have removed/updated react native patches introduced in new arch PR, as some of them has been resolved in rn 0.74.0
As for android - after updating/patching libs current build blocker is connected to react-native-clipboard
and its alignment to rn0.74.0 but as I can see @WoLewicki has already stared aligning that in this PR
Also in this thread @WoLewicki and @j-piasecki asked if they could join rn-upgrade efforts as there is many more libraries to be aligned with new changes in RN core
I'm wondering if https://github.com/Expensify/App/issues/40108#issuecomment-2062563600 may also have been fixed in RN 0.74
Im checking it right now and will give an update on that in next post on monday.
CC: @mallenexpensify @roryabraham @mountiny @WoLewicki @j-piasecki @arosiclair
I'm wondering if this issue may also have been fixed in RN 0.74
@MrRefactor If the Android build is working, can you check this issue, as it is critical and deploy blocking?
If Android build is working, can you check this issue too as it is critical and deploy blocking.
Android build is not working as commented here:
As for android - after updating/patching libs current build blocker is connected to react-native-clipboard and its alignment to rn0.74.0 but as I can see @WoLewicki has already stared aligning that in this https://github.com/react-native-clipboard/clipboard/pull/226
Commenting
Hi!
Update 22.04:
Draft PR link -> https://github.com/Expensify/App/pull/40548
Hi! Yesterday & today I managed to resolve issues with Airship - now it has min deployment version of 14.0 as marked in this commit.
I also created/updated patches for failing libraries while building on iOS & Android:
react-native-clipboard
rnmapbox/maps
- android only, working on patch for iOS react-native-svg
react-native-plaid-link-sdk
react-native
- needed to remove patch for inverted flat list as it was breaking build for iOS - to be fixed Build issues:
iOS -> issue related to nrmapbox/map
:
Android -> issue related to react-native-vision-camera
- will open an issue in vision camera repo:
e: /App/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/frameprocessors/VisionCameraProxy.kt:31:79 This API is provided only for React Native frameworks and not intended for general users. This API can change between minor versions in alignment with React Native frameworks and won't be considered a breaking change.
e: App/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/frameprocessors/VisionCameraProxy.kt:36:19 This API is provided only for React Native frameworks and not intended for general users. This API can change between minor versions in alignment with React Native frameworks and won't be considered a breaking change.
e: /App/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/frameprocessors/VisionCameraProxy.kt:36:47 This API is provided only for React Native frameworks and not intended for general users. This API can change between minor versions in alignment with React Native frameworks and won't be considered a breaking change.
e: /App/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/frameprocessors/VisionCameraProxy.kt:75:73 This API is provided only for React Native frameworks and not intended for general users. This API can change between minor versions in alignment with React Native frameworks and won't be considered a breaking change.
CC: @mallenexpensify @roryabraham @mountiny @WoLewicki
@mrousavy Can you help with the above comment?
@shubham1206agra VisionCamera is a bit tricky to bring to new arch. I have asked the Meta team about some implementation specifics regarding the frameProcessor
approach I currently use here: https://github.com/reactwg/react-native-new-architecture/discussions/167#discussioncomment-8938596
But so far I don't have a clear approach and I think this is still blocked. I am in contact with @philIip from meta and he's kind enough to help me find a solution to this using CodeGen soon.
Theoretically you could use the interop layer they built, and rip out all the Frame Processor stuff in VisionCamera Android - then it'll surely build.
But a real solution is to get away from the private APIs I currently use to inject the Frame Processor runtime into JSI, which I hopefully plan to solve with CodeGen/Fabric JSI View Managers.
We don't use Frame Processors in the App, or am I missing something? Also, looking at those lines: https://github.com/mrousavy/react-native-vision-camera/blob/b4413c5f9e40a26dc8588b3b52584b7aa6e56e49/package/android/build.gradle#L81-L87, since we don't use react-native-worklets-core
, Frame Processors should not even be added to the project. Or did something change recently @mrousavy ?
Hey - yup I know, Frame Processors are not enabled here anyways - but the VisionCameraProxy.kt
file will still be compiled because Java doesn't support preprocessor flags, so I can't really compile that code out (unless I create another file that stubs out the implementations and switches the source files at build.gradle with srcSets
, but that's a bit complex right now).
So these lines here in VisionCameraProxy.kt
will still be compiled, and if React Native removes them it will fail to compile - even though we are not calling VisionCameraProxy
in Expensify (because Frame Processors are not enabled).
So a workaround for now would be to rip out all the Frame Processors related stuff as a temporary patch, or to compile all that stuff out in build.gradle using srcSets
- either of those is only a temporary workaround.
The real solution will be VisionCamera migrating over to new-arch w/ CodeGen, Fabric and TurboModules - but I am still a bit blocked on that since I don't know how to add a JSI-only property to the <Camera>
view. I need to run C++ JSI code before that prop (frameProcessor
) gets passed to native Java/Swift, kinda like an RCT_ENUM_CONVERTER
but for JSI/C++.
I can get VisionCamera migrated to new arch / bridgeless for you next week or the week after that (currently on vacation in Italy ๐ฎ๐น), is that cool with you guys? cc @roryabraham
Do we use react-native-mmkv? That's already migrated, only a minor fix then I can merge that https://github.com/mrousavy/react-native-mmkv/pull/656
Do we use react-native-mmkv? That's already migrated, only a minor fix then I can merge that mrousavy/react-native-mmkv#656
We are not using react-native-mmkv
I can get VisionCamera migrated to new arch / bridgeless for you next week or the week after that (currently on vacation in Italy ๐ฎ๐น), is that cool with you guys? cc @roryabraham
In meanwhile I will try to patch workaround for that issue
I can get VisionCamera migrated to new arch / bridgeless for you next week or the week after that (currently on vacation in Italy ๐ฎ๐น), is that cool with you guys
To understand, is this a blocker for the 0.74 PR? @MrRefactor
I can get VisionCamera migrated to new arch / bridgeless for you next week or the week after that (currently on vacation in Italy ๐ฎ๐น), is that cool with you guys
To understand, is this a blocker for the 0.74 PR? @MrRefactor
Yes it is, Im working on the workaround connected with excluding Frame Processors described by @mrousavy to allow us to build android.
Update 23.04:
Main Draft PR link -> https://github.com/Expensify/App/pull/40548 Reanimated Draft PR link -> https://github.com/Expensify/App/pull/40775
Hi! Today I've been working on resolving issues reported yesterday with rnmapbox/maps
and react-native-vision-camera
- I wasn't able to fix them yet but work is ongoing.
I have also created a Draft PR for react-native-reanimated
version upgrade according to @roryabraham comment here. It will be hard to extract every library outside of main RN upgrade PR as those rely on changes in RN 0.74.0 and may cause blockers with RN 0.73.X but will try to extract as many as possible.
Added commit to main PR changing version of RN from RC to official release -> link
I will mark react-native-reanimated
PR open as soon as we make sure that it's working as expected.
CC: @mallenexpensify @roryabraham @mountiny @WoLewicki
Update 24.04:
Main Draft PR link -> https://github.com/Expensify/App/pull/40548 Reanimated Draft PR link -> https://github.com/Expensify/App/pull/40775
Hi! Today I kept working on issues reported with android and iOS builds.
I have created an issue in rnmapbox/maps
and posted questions about failing iOS builds here -> https://github.com/rnmapbox/maps/issues/3462
Also reproduced that issue on fresh react native 0.74.0 repo.
I have also created a patch for react-native-vision-camera
removing all code related to frame processors - still testing that patch if its working properly. It seems like I have issues with codegen, so need to doublecheck it. Also locked version of react-native-vision-camera
to make sure all patches introduced with new arch PR are still properly applied.
Also tomorrow @kbieganowski will start helping me with splitting this PR into smaller pieces to merge them to main before rest of the changes as discussed here -> https://github.com/Expensify/App/pull/40548#pullrequestreview-2015296489
CC: @mallenexpensify @roryabraham @mountiny
Update 25.04:
Main Draft PR link -> https://github.com/Expensify/App/pull/40548 Reanimated Draft PR link -> https://github.com/Expensify/App/pull/40775
Hi! Today I managed to make some progress with android builds. iOS issue is still not resolved as I'm trying to implement support for 0.74 to rnmapbox/maps
.
Updated libraries:
@react-native-picker/picker
to 2.7.5
,react-native-screens
to 3.31.1
,As going forward, I encountered an error related to new turbo modules linking introduced in 0.74.0. Error details:
/App/node_modules/react-native/ReactAndroid/cmake-utils/default-app-setup/OnLoad.cpp:74:10: error: use of undeclared identifier 'rncli_cxxModuleProvider'; did you mean 'rncli_ModuleProvider'?
return rncli_cxxModuleProvider(name, jsInvoker);
^~~~~~~~~~~~~~~~~~~~~~~
rncli_ModuleProvider
/App/android/app/build/generated/rncli/src/main/jni/rncli.h:19:30: note: 'rncli_ModuleProvider' declared here
std::shared_ptr<TurboModule> rncli_ModuleProvider(const std::string moduleName, const JavaTurboModule::InitParams ¶ms);
^
/App/node_modules/react-native/ReactAndroid/cmake-utils/default-app-setup/OnLoad.cpp:74:40: error: no viable conversion from 'const std::shared_ptr<CallInvoker>' to 'const JavaTurboModule::InitParams'
return rncli_cxxModuleProvider(name, jsInvoker);
^~~~~~~~~
/App/node_modules/react-native/ReactAndroid/build/prefab-headers/react_nativemodule_core/ReactCommon/JavaTurboModule.h:28:10: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'const std::shared_ptr<CallInvoker>' to 'const InitParams &' for 1st argument
struct InitParams {
^
/App/node_modules/react-native/ReactAndroid/build/prefab-headers/react_nativemodule_core/ReactCommon/JavaTurboModule.h:28:10: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'const std::shared_ptr<CallInvoker>' to 'InitParams &&' for 1st argument
/App/android/app/build/generated/rncli/src/main/jni/rncli.h:19:116: note: passing argument to parameter 'params' here
std::shared_ptr<TurboModule> rncli_ModuleProvider(const std::string moduleName, const JavaTurboModule::InitParams ¶ms);
I couldnt reproduce that on bare 0.74.0 react-native repo and I keep looking for a solution to that. One of the paths I want to check is usage of react-native-config
whether its impacting that issue at any point.
CC: @mallenexpensify @roryabraham @mountiny @mrousavy @WoLewicki
Update 26.04:
Main Draft PR link -> https://github.com/Expensify/App/pull/40548 Reanimated Draft PR link -> https://github.com/Expensify/App/pull/40775
Hi! I'm still resolving issues from previous PR - trying to fix new turbo modules linking errors as well as align rnmapbox/map
to work with rn 0.74.
I have also started working on 0.74.0 support for react-native-pager-view
as its breaking android builds, and needs to be aligned as well.
CC: @mallenexpensify @roryabraham @mountiny @WoLewicki
@MrRefactor I just merged a PR that upgrades react-native-quick-sqlite with RN 0.74 compatibility
Update 29.04:
Main Draft PR link -> https://github.com/Expensify/App/pull/40548 Reanimated Draft PR link -> https://github.com/Expensify/App/pull/40775
Hi! I'm still resolving android build issues connected to new linking of the packages.
rnmapbox/maps
to work with rn 0.74.0 on iOSUpdated libraries:
@expensify/react-native-live-markdown
to 0.1.69
react-native-gesture-handler
to 2.16.0
@react-native-async-storage/async-storage
to 1.23.1
Updated patches:
@rnmapbox/maps
react-native-vision-camera
Added patches:
react-native
-> Patch with disabling bridgeless mode on iOS as App was failing - I will check the reason of app failing with bridgeless after fixing android build issues I have also patched react-native-pager-view
for android, it seems to be working fine, need to create patch for iOS
as well.
NOTE: I'm OOO starting Wednesday, will be back on Monday!
CC: @mallenexpensify @roryabraham @mountiny
Update 30.04:
Main Draft PR link -> https://github.com/Expensify/App/pull/40548 Reanimated Draft PR link -> https://github.com/Expensify/App/pull/40775
Hi!
I managed to make some progress with android builds - resolved codegen issues with react-native-pager-view
, react-native-airship
and react-native-geolocation
- still need to fix react-native-webview
codegen issues.
I couldnt reproduce the issue on fresh rn 0.74 app.
NOTE: I'm OOO until the end of the week.
CC: @mallenexpensify @roryabraham @mountiny
@roryabraham I'm putting this in the Summer release, but if there's a particular project that it's necessary for -- let me know. As I understand it, we didn't need it for QBO.
Ok, sounds good. Hopefully we'll finish this up soon after @MrRefactor is back from OOO
slack context: https://expensify.slack.com/archives/C02NK2DQWUX/p1709024519896479
Problem
There are some new arch problems that should be fixed in RN 0.74+. So far that's the only thing I'm aware of in 0.74+ that we'll need, but it takes a long time to upgrade. It's not necessarily a blocker but unless we upgrade we'll have to use patches.
Solution
Let's get the ball rolling on the RN 0.74 upgrade. If there are issues in the RC we should report them to Meta.
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @Issue Owner
Current Issue Owner: @dylanexpensify