-
Notifications
You must be signed in to change notification settings - Fork 919
fix(platform-ios): fix sourceDir
detection
#1444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(platform-ios): fix sourceDir
detection
#1444
Conversation
@grabbou wdyt? |
Apologies for the waiting time. The reason I didn't act on this PR earlier was that I was thinking how to move forward with this one. Like @tido64 said, all the logic around That said, I am hesitant to add additional complexity to something that already works, as well as change the way we resolve a Podfile - at the risk of breaking this for our other users. Instead, I would work on adding a temporary configuration option to override what does not work. For example, we could allow overriding |
// This is a temporary fix for #1435. In certain repos, the Xcode project can | ||
// be generated by a tool. The only file that we can assume to exist on disk | ||
// is `Podfile`. | ||
const sourceDir = podfile ? path.dirname(podfile) : path.dirname(projectPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not change this one to be honest, sourceDir
is not needed for autolinking
, so there's no need to adjust it for cases when xcodeproj
doesn't exist. It is needed for legacy link
command and in the case of a missing xcodeproj
, that would fail anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like it is being used for autolinking:
project_root = Pathname.new(config["project"]["ios"]["sourceDir"]) |
Without this change, we hit errors similar to this when running pod install
:
[!] No podspec found for `ReactTestApp-DevSupport` in `..`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You’re right 😅
But it's not fundamentally changing how you're resolving a Podfile today. The logic is still the same for the success case. Only in the case of it failing, are we resorting to a glob search. I don't understand how that is a risk? If it was failing before, it wouldn't be any worse with the current change. |
Reopening as it looks like that’s our only way to go in this case for time being. |
After taking another pass and your explanations @tido64, it looks good 👍 |
@tido64 published |
Thanks for backporting it, @thymikee. |
Hi @tido64, I'm facing a problem with podspec path resolution on one of the packages I'm using: react-native-emarsys-wrapper. This change causes sourceDir to resolve to I'm currently working around this by patching react-native-emarsys-wrapper to remove sample/ios/Podfile to avoid incorrect sourceDir resolution. Is there a better way to resolve sourceDir, such as editing Environment
|
@joshchoo: You can explicitly disable it in your This way you don't have to patch the package. Is the |
@tido64, thanks for your help! Disabling autolinking via react-native.config.js works for my case. |
Summary:
This is a minimal changes version of #1436. After speaking with @grabbou, I learned that most of the props in
config
are going away, so we agreed to make as little changes as possible and instead focus onnext
.Resolves #1435
Resolves microsoft/react-native-test-app#375
Test Plan:
Curren tests should pass: