You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CocoaPods could not find compatible versions for pod "RCT-Folly" which required re working example/ios/Podfile.lock and more upgrades to the example app versions.
An error occurred while processing the post-install hook of the Podfile.: which required removing __apply_Xcode_12_5_M1_post_install_workaround from example/ios/Podfile.
After clearing this hurdles, I needed to update the iOS target version from ~11 to ~15.
Further errors continued with implicit instantiation of undefined template 'std::char_traits<fmt::internal::char8_type>' which required further react-native version upgrades.
After overcoming all these challenges, the project was finally starting to build successfully when I realized that all the underlying example app code was going to need updates as well. You can see all the application code that requires changing here: https://react-native-community.github.io/upgrade-helper/?from=0.73.11&to=0.79.2
And all of this was just for the iOS portion of the example app!
At this point, I'm starting to think that the best way forward is to simply build a new example app from scratch. But I find myself asking: how can we avoid this kind of upgrade pain in the future.
My experience tells me that Expo is the way to minimize these challenges. They abstract away most of the native code management by using plugins, but in exchange you have to follow some additional build steps to get a development build. This still requires a fair bit of complexity and upkeep.
With all that said, I think the most practical solution is to remove the example app.
If this repo is being used in other actively maintained projects, that is by far the best way to ensure it is healthy.
If this isn't acceptable, then I suggest moving to Expo development builds to work within the well-supported and well-documented upgrade paths provided by Expo for each react-native upgrade cycle.
Hey @bbuchalter, thank you so much for looking into it.
For now I will share a few things without coming to a conclusion yet:
In my experience, upgrading React Native does take a number of hours for each minor version (eg. 0.73 to 0.74). As you suggest, it might be hard to justify this for the example app. We would need to upgrade to at least 0.77.x for now - the oldest currently supported version.
For the Plum Village App which uses this package, we do not use Expo. So it could be helpful for us to have a non-Expo based example app to ensure it works with that configuration.
So another option is to recreate the example app following Get Started Without a Framework and then recreate the code for the example app.
This could also be a great opportunity to review the README instructions to ensure they are up-to-date and complete.
On the other hand, it might also be helpful for Expo users to have an Expo example. However I do not have experience with Expo and could not even be sure that it works with Expo - would welcome any input here.
Would it be beneficial to offer both examples (Expo and non-Expo)?
I would be very happy to read any further thoughts you may have on which direction is best.
tl;dr
The example app is so out of date, I believe the best course of action is to either:
A decision would need to be made by maintainers. 🙇♂️
The long version
While following the excellent instructions in
CONTRIBUTING.md
I encountered this error:This is a known issue that was fixed by facebook/react-native#39555 and released in v0.72.9.
After making that upgrade, I proceeded to encounter a series of other errors:
CocoaPods could not find compatible versions for pod "RCT-Folly"
which required re workingexample/ios/Podfile.lock
and more upgrades to the example app versions.An error occurred while processing the post-install hook of the Podfile.
: which required removing__apply_Xcode_12_5_M1_post_install_workaround
fromexample/ios/Podfile
.implicit instantiation of undefined template 'std::char_traits<fmt::internal::char8_type>'
which required further react-native version upgrades.After overcoming all these challenges, the project was finally starting to build successfully when I realized that all the underlying example app code was going to need updates as well. You can see all the application code that requires changing here: https://react-native-community.github.io/upgrade-helper/?from=0.73.11&to=0.79.2
And all of this was just for the iOS portion of the example app!
At this point, I'm starting to think that the best way forward is to simply build a new example app from scratch. But I find myself asking: how can we avoid this kind of upgrade pain in the future.
My experience tells me that Expo is the way to minimize these challenges. They abstract away most of the native code management by using plugins, but in exchange you have to follow some additional build steps to get a development build. This still requires a fair bit of complexity and upkeep.
With all that said, I think the most practical solution is to remove the example app.
If this repo is being used in other actively maintained projects, that is by far the best way to ensure it is healthy.
If this isn't acceptable, then I suggest moving to Expo development builds to work within the well-supported and well-documented upgrade paths provided by Expo for each react-native upgrade cycle.
What path do you think is best @Polarisation ?
The text was updated successfully, but these errors were encountered: