[Gutenberg] Upgrade React Native 0.71.11
#20956
Conversation
No other than reason than me looking at the CocoaPods setup and realizing we were a few versions behind.
Despite it working during the prototype stage, I wasn't able to get the XCFrameworks out of the ZIP archive, but it works fine with the tar.gz. I suspect this has to do with the folder(s) generated when decompressing.
These are unnecessary at the moment but will be when we move to Gutenberg via XCFramework
The advantage of this approach is that downloading the archive is only necessary when using a local spec. Defining the logic in the local spec itself keeps everything self contained and saves us from having to conditionally call the `pre_install` hook.
The idea was to use a local spec and interpolated the desired commit SHA1 in the `source` to download the corresponding `tar.gz`. However, CocoaPods has some issues with local specs that use `http` `source`, as documented in: - CocoaPods/CocoaPods#10288 (comment) - https://github.com/firebase/firebase-ios-sdk/blob/68b39b8edf61f6e643e2396e712c7c67e0f146ff/scripts/pod_lib_lint.rb#L70-L78 Using a remote spec doesn't have the same issue, and the cost in terms of extra computation and storage is negligible when compared to building and hosting the `tar.gz` archives.
This was done to address the following CI failure when building with the Gutenberg XCFramework: ``` ▸ Linking WordPress⚠️ ld: Could not find or use auto-linked library 'swiftCompatibility56' ❌ ld: symbol(s) not found for architecture x86_64 ``` https://buildkite.com/automattic/wordpress-ios/builds/14356#01885545-c05a-43a8-b475-d0d683857672
Because the latest XCFramework setup ships without testing compilation.
Co-authored-by: Tony Li <tony.li@automattic.com>
Co-authored-by: Tony Li <tony.li@automattic.com>
fluiddot
force-pushed
the
gutenberg/upgrade/react-native-0.71.11
branch
from
28a6903
to
31a4f10
Compare
…rade/react-native-0.71.11
| # When referencing via a tag or commit, we download pre-built frameworks. | ||
| return if options.key?(:tag) || options.key?(:commit) |
There was a problem hiding this comment.
These conditions will never be met as gutenberg_dependencies is only called when using Gutenberg locally, i.e. it will always reference the pod using a path.
There was a problem hiding this comment.
Maybe it makes sense to keep it in case gutenberg_dependencies is used somewhere else in the future 🤔.
Gutenberg/cocoapods_helpers.rb
Outdated
| # When using an absolute path, we get this error, notice the duplicated "/Users/gio/Developer/a8c/wpios": | ||
| # | ||
| # [!] An error occurred while processing the post-install hook of the Podfile. | ||
| # | ||
| # No such file or directory @ rb_sysopen - <GUTENBERG_MOBILE_PROJECT_PATH>/gutenberg/node_modules/react-native/package.json | ||
| # |
There was a problem hiding this comment.
If we confirmed that React Native preprends $PWD, I think we don't need to share details about the error. Hence, we could consider removing this part.
There was a problem hiding this comment.
I've applied this suggestion via 7e11b1e.
| @unknown default: | ||
| fatalError() |
There was a problem hiding this comment.
For some reason, when building the app using a local installation of Gutenberg, this line (and similar ones below) are giving the following warning when building: Default will never be executed
However, this is not the case when building using the XCFramework 🤔
# Conflicts: # Gutenberg/version.rb # Podfile.lock
…o gutenberg/upgrade/react-native-0.71.11
|
The CI jobs are failing with the following error after incorporating the latest changes from The failure is related to this PR and the usage of the library Lines 447 to 449 in eb05889 Now that Gutenberg is integrated via XCFramework, the |
# Conflicts: # WordPress/WordPress.xcodeproj/project.pbxproj
This proposes replaces usage of `SDWebImage` in the new `MemoryCache` following the comment #20956 (comment). It's only being used in one instance, to calculate the cost of objects added to the cache. What's the difference between not passing in a cost and using `sd_memoryCost`? I'm not sure, so I'll share my current understanding and ask for feedback. For images, I don't see a difference because I think the cost is the image's size in bytes. For gifs (also `UIImage`s), the cost calculation seems more complex since I think it's only the number of frames loaded into memory (not the frames that are kept on disk). This PR is meant to start a conversation about which option to take: a. Let `NSCache` calculate the cost and remove `SDWebImage` from the Podfile b. Re-implement a cost calculation and remove `SDWebImage` from the Podfile c. Leave things as-is and close this PR The assumption here is that by removing `SDWebImage`, we're not importing the library twice (once here and once in Gutenberg as a transitive dependency of a RN library).
This proposes replaces usage of `SDWebImage` in the new `MemoryCache` following the comment #20956 (comment). It's only being used in one instance, to calculate the cost of objects added to the cache. What's the difference between not passing in a cost and using `sd_memoryCost`? I'm not sure, so I'll share my current understanding and ask for feedback. For images, I don't see a difference because I think the cost is the image's size in bytes. For gifs (also `UIImage`s), the cost calculation seems more complex since I think it's only the number of frames loaded into memory (not the frames that are kept on disk). This PR is meant to start a conversation about which option to take: a. Let `NSCache` calculate the cost and remove `SDWebImage` from the Podfile b. Re-implement a cost calculation and remove `SDWebImage` from the Podfile c. Leave things as-is and close this PR The assumption here is that by removing `SDWebImage`, we're not importing the library twice (once here and once in Gutenberg as a transitive dependency of a RN library).
Related to wordpress-mobile/gutenberg-mobile#5874
This PR contains the following changes:
upgrade/react-native-0.71.8. This incorporates the needed changes for the RN upgrade coming from Gutenberg.To test:
Follow testing instructions from WordPress/gutenberg#51303.
Regression Notes
Potential unintended areas of impact
None apart from the editor.
What I did to test those areas of impact (or what existing automated tests I relied on)
Manual testing and CI tests.
What automated tests I added (or what prevented me from doing so)
N/A
PR submission checklist:
RELEASE-NOTES.txtif necessary.UI Changes testing checklist: