RFC for Improving CocoaPods support #18
Conversation
|
|
||
| For teams adding React Native to existing apps CocoaPods support let's RN be treated as a dependency like all of the other ones. CocoaPods is built with a lot of escape valves for consumers to fix issues at runtime (you see people passing around `post_install` [fixes](https://github.com/facebook/react-native/issues/20182#issuecomment-409131862) for example, and I built a [CocoaPods plugin](https://github.com/orta/cocoapods-fix-react-native) to try consolidate them all) | ||
|
|
||
| I think one of the a key reasons for the drift between the CocoaPods support and the Xcode projects is because they're not mapped together. |
There was a problem hiding this comment.
What implications does this have to the existing consumers of the Xcode projects? My understanding is that they'll be unused by CocoaPods. How will this ensure that CocoaPods and the existing Xcode projects stay in sync?
There was a problem hiding this comment.
That is to say, we've had bugs such as this which were a result of an Xcode project being misconfigured. How will changing this CocoaPods structure allow for dependency changes like these to be addressed?
There was a problem hiding this comment.
I believe man-made Xcode projects in the repo must die, they must be build artifacts of Buck packages (Buck can generate Xcode projects). Nobody should configure builds in more than one place.
|
|
||
| ## Motivation | ||
|
|
||
| For teams adding React Native to existing apps CocoaPods support let's RN be treated as a dependency like all of the other ones. CocoaPods is built with a lot of escape valves for consumers to fix issues at runtime (you see people passing around `post_install` [fixes](https://github.com/facebook/react-native/issues/20182#issuecomment-409131862) for example, and I built a [CocoaPods plugin](https://github.com/orta/cocoapods-fix-react-native) to try consolidate them all) |
|
I love the idea of decoupling dependencies and slicing existing huge CocoaPod file! Do we have a strategy to address the fact that some deps of RN does not have Cocoapod version? Let's consider Folly, for example. We are starting to use Folly more and more in the our new efforts and we have to have ability to depend on its the latest version available. Even we if can hack a Cocoapod for Folly (we actually tried and failed), we cannot expect that Folly contributors will fix the Cocoapod-based configuration every time they change something. So, I believe, we have to find a way to produce a Folly Cocoapod automatically from existing Buck (or cmake) configuration. Same story with Yoga. So, I would start the slicing from decoupling those. |
|
|
||
| ## Basic example | ||
|
|
||
| CocoaPods support in React Native is a tad tricky, because it’s trying to map a complex set of Xcode projects into a single dependency. The Podspec for React Native does a lot of work under the hood at ~300 LOC. This is, in part, because we use a CocoaPods abstraction called subspecs to consolidate out the React Native library into one single library. |
There was a problem hiding this comment.
I would also start from killing those hand-written projects. We have to figure out a way to build them automatically from Buck files which should be (they actually are) source of truth of the build configuration.
There was a problem hiding this comment.
I read up some of the buck docs - this might be possible by having buck output the compiler options into JSON and then having the pod specs capture that, I need to try prototype it to be sure though
| date: 2018-08-15 | ||
| --- | ||
|
|
||
| # RFC0003: CocoaPods Support Improvements |
There was a problem hiding this comment.
I believe this is RFC0005.
|
@orta seems like people are in favor of this. What's the hold-up? Can you just go ahead and make this happen? |
|
Yep, it can happen. It's mainly been blocked on us upgrading to the latest versions of React Native at Artsy ( artsy/emission#1210 ) so that we can use/test it in-house. Which is on-going, and sporadically worked on by a few of us in our spare time. So, it might take some time for me to get around to it |
|
I merged this RFC then (feel free to follow-up with small changes, given that you were still iterating on it a bit). I'll let you do this whenever you get around to do it. |
This should make CocoaPods support match the Xcode projects currently used, and provides a technique to make sure that all testing can be done offline,