fix: add more guard conditions for retrieving buildConfig from XcScheme

[AnnatarHe]

Summary:

just an enhancement. Add more guard conditions when retrieving buildConfig from XcScheme.

Test Plan:

add a new project to /ios/ folder looks like this:

|-- ios
     |-- foo.xcodeproj
     |-- bar.xcodeproj

when running npx react-native run-ios it would throw an accurate error message.

Checklist

• Documentation is up to date to reflect these changes.
• Follows commit message convention described in CONTRIBUTING.md

Note:

I'm not good at English, please feel free to correct the error message. Thanks.

[TMisiukiewicz]

Hi @AnnatarHe, thanks for your PR! I believe it's a follow up to the issue #1908 you raised some time ago, unfortunately we had to prioritize other stuff at this moment. I think this is a great starting point, however I feel like we could improve the DX for your solution 🙂

[TMisiukiewicz]

I believe in that case, instead of forcing to remove the project, we should prompt user which project to use -> maybe store it in cache?

[AnnatarHe]

I’m not sure whether we should prompt the user to choose one option for processing. Additionally, it seems that the current process does not support different projects. the previous code used a simple [].find to select the first available option, but I guess this is not the only occurrence.

this PR just corrects the error message here. If the CLI is going to support multiple projects in future, we can easily identify where we need to make changes.

additionally, I’m not familiar with this project, so I don’t know how to show a prompt to the user in this project 😂

If necessary, maybe we can raise another pull request after this one is merged? This one is for correcting error messages, and the next one will be for enhancing the DX.

[thymikee]

@tido64 @kelset would you mind taking a look? I recall similar setups for RNTA, so would be cool to not break something that we don't intend

[tido64]

@tido64 @kelset would you mind taking a look? I recall similar setups for RNTA, so would be cool to not break something that we don't intend

Thanks for the ping! I haven't tested it (I'm supposed to be afk for the holidays :P), but I'm pretty certain this is going to break general usage, including RNTA. I think I've mentioned this at multiple occasions before:

• You cannot assume where .xcodeproj lives — they can be anywhere
• The only way to find .xcodeproj is to parse .xcworkspace
• A .xcworkspace can reference multiple .xcodeproj
• There is only one thing you can assume: where there is a Podfile, a .xcworkspace will be generated next to it

Maybe this should be in a comment in this part of the code to avoid reintroducing wrong assumptions?

[AnnatarHe]

Hi @tido64 ,Thank you for your review.

I’m sorry, my English is not good. I don’t really understand what your concern is. This PR only provides some accurate error messages. It doesn’t make any assumptions. The sourceDir is passed by the parent function and the main logic remains the same as before.

What changes should I make? Or should I just close it?

[tido64]

I’m sorry, my English is not good. I don’t really understand what your concern is. This PR only provides some accurate error messages. It doesn’t make any assumptions. The sourceDir is passed by the parent function and the main logic remains the same as before.

Basically, sourceDir is not enough information to determine the location of the "main" .xcodeproj. There are plenty of scenarios where it simply does not exist or is non-trivial to find. For example:

my-app
├── package.json
└── packages
    ├── app
    │   ├── App.xcworkspace  # no .xcodeproj here!
    │   ├── Podfile
    │   └── package.json
    ├── core
    │   ├── Core.podspec
    │   ├── Core.xcodeproj
    │   ├── package.json
    │   └── src
    ├── module-1
    │   ├── Module1.podspec
    │   ├── Module1.xcodeproj
    │   ├── package.json
    │   └── src
    └── module-2
        ├── Module2.podspec
        ├── Module2.xcodeproj
        ├── package.json
        └── src

Or in a hybrid scenario:

hybrid-app
├── app
│   └── src
├── core
│   ├── Core.podspec
│   └── src
├── module-1
│   ├── Module1.podspec
│   └── src
├── ReactNativeModule
│   ├── Podfile  # no .xcodeproj here!
│   ├── ReactNativeModule.podspec
│   ├── package.json
│   └── src
├── App.xcworkspace
└── Podfile

Hopefully the examples above make sense. We cannot throw just because we cannot find .xcodeproj. The way we look for it is currently too simple.

An .xcodeproj can also contain many schemes. Simply picking the first one is also wrong, but that's a different issue.

What changes should I make? Or should I just close it?

I think we should close it. Or if you'd like to, it would be nice to have a comment in code explaining all of this so the next person doesn't make the same mistake.

[AnnatarHe]

@tido64 Thanks, your description is perfect, I've learned a lot.

this MR got updated, just add a simple comment and use .endsWith to replace the .includes