Repository navigation
Conversation
|
Hi @Marve10s! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
meta-cla
Bot
added
the
CLA Signed
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
facebook-github-tools
Bot
added
the
Shared with Meta
|
@fabriziocucci has imported this pull request. If you are a Meta employee, you can view this in D122043396. |
|
@fabriziocucci merged this pull request in d45fc2d. |
… and Expo's tagged block withPodDeploymentTarget's regex fit only the template's multi-line react_native_post_install(...) call: a one-line call put the block inside the next multi-line call, or failed with "no react_native_post_install call", and a CRLF Podfile failed the same way. The block now goes right after the `post_install do |installer|` line (React Native never touches resource bundles, so it can run first), through @expo/config-plugins' withPodfile and mergeContents instead of a hand-rolled marker scheme. A CRLF Podfile keeps its line endings, and the previous version's begin/end block is replaced, not doubled. Cites the upstream fix, react/react-native#58687 (d45fc2d289, not in 0.88.0), and says to drop the plugin on the first release with it. Tests: example/plugins/withPodDeploymentTarget.test.js runs the plugin through Expo's real mod compiler on the SDK 54 template, twice, and runs the generated block under Ruby. `npm test` now runs the example's tests. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P3R8RBUkNXQyci9DTeccAg
1 participant
Summary:
CocoaPods resource bundles can retain deployment targets such as iOS 9.0 even after React Native raises their library target to iOS 15.1. Xcode 27 rejects those bundle targets, blocking the build described in #58555.
updateOSDeploymentTargetonly visits each pod's native target. Include its resource bundle targets in the same traversal so every bundle receives React Native's minimum deployment target while preserving higher existing values.Fixes #58555.
Changelog:
[IOS] [FIXED] - Apply React Native's minimum iOS deployment target to CocoaPods resource bundles.
Test Plan:
ruby packages/react-native/scripts/cocoapods/__tests__/utils-test.rb --name test_updateOSDeploymentTarget_updatesNativeAndResourceBundleTargets: passes with 1 test and 3 assertions. Before the fix, it fails because bundle targets remain at 9.0 and 12.4. Covers multiple bundles, Debug and Release configurations, missing deployment targets, and preservation of higher values.ruby packages/react-native/scripts/cocoapods/__tests__/utils-test.rb: 67 tests, 170 assertions, 2 failures. Untouched main atba1ede621cf5fc63b81fc3e2645f3014c0fe0c03has the same failures intest_SetGCCPreprocessorDefinitionForHermes_itSetsThePreprocessorForDebugandtest_updateSearchPaths_whenUseFrameworks_addsSearchPaths.pod installor a full Xcode build.git diff --check: passes.A full Xcode 27 build was not run.