Make iOS linking to Podfile or directly linking as framework an option for library maintainer and for consumer about cli HOT 11 CLOSED

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:

1. Third party dependencies are best managed as cocoapods. I certainly do this, and created react-native-pod to make this easier and declarative from the package.json level. Every package that i have seen the "drag and drop framework" instruction was available as a CP, and deploying this way made life easier.

2. This creates a potential conflict with RN libraries that have podspecs. Once you create a Podfile, react-native link runs around adding all of them to the Podfile, and that creates a dependency mess. For this I am hoping that the RN crew might come up with a react native link --without-pods flag, but for now I have the more-hacky react-native-linknopod that basically does this. So I run react-native linknopod instead of react-native link to do my... link.

3. 3P cocoapod dependencies also make library development harder, because the CPs are attached to the app, while the library is developed elsewhere. For this, one needs to make sure to import the appropriate header paths (my react-native-swift-cli templates include this relative path reference) but since often lib development is done elsewhere, supporting the more complex path from the RN native library to your test app's cocoapod path is required. For this, I made and use react-native-fix-pod-links. Its a slightly more complicated devex for a library maker, but still pretty high velocity imho.

4. Longer term, it would be ideal to centralize all the dependency tree into cocoapods. The split personality of directly linked static libraries and cocoapods increases the energy a library developer needs to devote to RN-specific issues of deployment, which decreases native developer efficiency and reduces the universe of native developers who can work on RN-relevant projects. CocoaPods ain't perfect, but it has great community support and it removes an otherwise difficult concern - dpepndency management - from RN core.

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?

from cli.

from cli.

CC: @rhdeck - I would love to hear your input on the CocoaPods support.

from cli.

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

from cli.

--ios_linking_method pod|xcodeproj could be an option

from cli.

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.

from cli.

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?

from cli.

@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. 😄

from cli.

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 react-native unlink react-native-gesture-handler (for example) and then react-native link react-native-gesture-handler. Very few None of them worked out of the box. Most All ended up having to be manually linked using the classic three-step process.

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 react-native link feel pretty "broken" to end users in the short term.

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.

from cli.

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

from cli.

link is soon to be removed. Should be fixed with autolinking available since RN 0.60+

from cli.