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
Make iOS linking to Podfile or directly linking as framework an option for library maintainer and for consumer #37
Comments
CC: @rhdeck - I would love to hear your input on the CocoaPods support. |
OK, I blew away my previous comment because I didn't understand the issue at the time and managed to comment on the wrong thing. So my thinking is:
I would not recommend RN create a specific mechanism of adding native dependencies outside of CP - creating more mechanisms increases developer work, and it increases the surface area of concerns that RN has, which would slow development in other, higher return areas. @grabbou is this the kind of feedback you were looking for? |
This would be so helpful. I feel like my pod file gets a new hack to keep the React pods and subspecs working every other week. Simply the —without-pods would be enough. Though it would require pods already added to the pod file to not be linked |
|
Looking at this issue again in order to make sure our CocoaPods support is first-class before 0.60 is cut. @bartolkaruza, I messaged you on Discord to discuss some of the details and sync our work. |
Do I understand correctly that the use-case presented in this issue is to let certain libraries still be linked the "standard" way even though the 3rd party library ships with Podspec? Why they ship with it in first place then? |
@grabbou the answer to your question is that the library is trying to support both of the ways that RN can be deployed - via direct SLs or through CP. But if one deploys RN via the currently-stock SL method and then adds a Podfile to support 3P libraries (like react-reality does), a subsequent In my experience, that's a mess. The purpose of This complexity is a necessary consequence of RN allowing two mechanisms for adding native modules, which is a separate issue, as it were. 😄 |
Thanks for explanation. Makes sense. This is going to be less of an issue
now that CocoaPods is going to be standard for all new projects from 0.60
on. We will still have to support older projects tho.
I guess a flag to manually choose linking method is going to be a good
solution to this problem. And we are going to default to CocoaPods when
Podfile is present in both places.
If anyone is willing to contribute this, please do! Happy to help.
…On Mon, 11 Mar 2019 at 14:57, Ray Deck ***@***.***> wrote:
@grabbou <https://github.com/grabbou> the answer to your question is that
the library is trying to support both of the ways that RN can be deployed -
via direct SLs or through CP. But if one deploys RN via the currently-stock
SL method and then adds a Podfile to support 3P libraries (like
react-reality does), a subsequent react-native link brings over the
package as a pod, which then brings the train of dependencies, including a
second shot at RN itself.
In my experience, that's a mess. The purpose of react-native-linknopod
and of this issue is to give more control over how the package gets added
to the app itself, so that one can have RN modules via direct SL binding,
and have the Podspec handle other concerns.
This complexity is a necessary consequence of RN allowing two mechanisms
for adding native modules, which is a separate issue, as it were. 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWcxv4a3dmi5_BeKSEXNYNRU8UD0h95ks5vVmDjgaJpZM4ZJ-kU>
.
|
I spent today trying to move to a CocoaPods-based setup and didn't get very far. I went through each of the native modules I used, and ran I would love to see CocoaPods become "first-class", but if that means having to manually link everything I'd prefer the old approach. I think these issues can probably be resolved by fixing up the relevant projects' Podspecs, but I'm new to CocoaPods and not quite ready to send out all the PRs. Going forward with CocoaPods now will probably push maintainers to try and fix up their Podspecs (assuming it's possible), but it will probably make UPDATE After more debugging, I'm realizing this issue has to do with my use of yarn workspaces. Having a flag to choose linking would allow me to circumvent it, but the right solution would certainly be to fix up support for yarn workspaces. I've created #352 to track this. My apologies for commenting on this issue with a mostly unrelated complaint. |
There’s no way I’d dependencies via pods, it’s so painful. react-native-linknopod is a great alternative. I tend to use this for Android only |
|
Since the introduction of the Cocoapods check in this PR, any project with a Podfile linking any library with .podspec will be linked by adding the library to the cocoapods. Although this is theoretically the desired behaviour and a much better way to link libraries, there are various reasons why some libraries need to be linked in the direct way instead. Most app projects require cocoapods for something during their lifecycle. After adding cocoapods, adding several high profile react native libraries becomes much more complicated. This is a proposal to address that.
With this issue I propose two things:
react-native link
play nicely with CocoaPods-based iOS projects. facebook/react-native#15460 (comment))react-native link
to specify individual libraries to link directly through the project, instead of through the Podfile.One example of why this would help is react-native-firebase, where their install for iOS documentation describes:
and the
react-native-firebase
Some related communication from @chrisbianca: invertase/react-native-firebase#838 facebook/react-native#15460 (comment)
Other scenarios where linking to Podfile is causing issues is react-native-config and react-native-branch.
If 1. is implemented, the library maintainers can resolve those issues for their users, by forcing link to ignore the Podfile and the libraries .podspec. 2. can be used by the consumers of those libraries to implement a stable workaround until the libraries in question have resolved it for them.
Just an additional link as to why this is important, here is a workaround posted to one of the issues which basically instructs the user to delete the Podfile, then run link, then add the Podfile again: lugg/react-native-config#187 (comment)
This shouldn't be necessary :)
The text was updated successfully, but these errors were encountered: