reproduce update_ats_in_plist file resolution error by adding plist in target #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reproduces the inability of the
update_ats_in_plist
function added to a pod installation script in React Native 0.73 to correctly find Info.plist files in targets, causing a pod install failure when additional targets are added.To trigger this, the PBXFileReference may need a name field, which Xcode doesn't necessarily add, but the
addPbxGroup
function of the xcode NPM module does (it's possible the name field is added under other circumstances, too, I just don't know which ones). To create a reproduction, I added the target by going to File > New > Target > Notification Service Extension in Xcode, and then added the name field to the file reference by hand. But the actual failure I'm experiencing in the wild is with some tooling that uses thexcode
module method, which does add the name field by default.As you can see, the error message here is, "The plist file at path
/Users/runner/work/reproducer-react-native/reproducer-react-native/ReproducerApp/ios/NotificationServiceExtension-Info.plist
doesn't exist.", but the file does exist, theupdate_ats_in_plist
method simply looks at the wrong path because its file resolution logic is incorrect, as detailed by Evan Bacon here.