Skip to content
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

RFC for Improving CocoaPods support #18

Merged
merged 1 commit into from
Jan 21, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
117 changes: 117 additions & 0 deletions proposals/0003-cocoapods-support-improvements.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,117 @@
---
title: CocoaPods Support Improvements
author:
- Orta Therox
- Eloy Durán
date: 2018-08-15
---

# RFC0003: CocoaPods Support Improvements
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is RFC0005.


## Summary

Simplify CocoaPods support in React Native, by reducing the differences between how CocoaPods maps React Native into the existing set of Xcode projects.

## 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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


If we split the `React.podspec` into many podspecs, one per Xcode project. Roughly ~10ish Podspecs per React Native release. These would match up one-to-one to the Xcode projects so that when CocoaPods support is broken in React Native, an error report would make it obvious which part of the project is broken.

This means we can also move React Native and we can get CocoaPods support back in CI. This route allows CocoaPods support to be tested without network access (all the required information would be inside the same)

The CocoaPods React dependency would then depend on React-ART, and React-RCTSettings etc.

## 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)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/support let's/support, this lets


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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

@shergin shergin Aug 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Detailed design

```sh
rm React.podspec

touch React/React.podspec
pod spec lint React/React.podspec

touch Libraries/ART/React-ART.podspec
touch RNTester/React-RNTester.podspec
touch Libraries/Blob/React-RCTBlob.podspec
# etc
```

Implementing that is reasonably straight forwards. Then we have two ideas about how the Podspecs can be distributed.

- Podspecs are shipped to CocoaPods trunk when a release is deployed. This is the simplest for library consumers, but a bit more taxing on release deployment. It must have been discussed before, but they were classed as being deprecated. I'm open for this RFC to be about bringing that back.

- Or... The React Native repo is turned into a Podspecs Repo. This would mean making a Specs folder in the root of the react-native repo, and putting in the CocoaPods Podspecs. People using CocoaPods would include React Native at the top of their Podfiles like so:

```ruby
source 'https://github.com/facebook/react-native.git'
source 'https://github.com/CocoaPods/Specs.git'

pod "React"
pod "React-Devtools"
```

The changes would convert the React Native repo to act like a specs repo:

```
$ ls .

[... as it is today]
Specs
[... as it is today]

$ tree Specs

React
├── 0.57.0
│ └── React.podspec.json
└── 0.57.1
└── React.podspec.json
React-ART
├── 0.57.0
└── React-ART.podspec.json
└── 0.57.1
└── ...
React-RCTSettings
├── 0.57.0
└── 0.57.1
Yoga
├── 0.45.0-rc.2.React
└── 0.48.4.React
[.. for all the specs]
```

## Drawbacks

Why should we _not_ do this? Please consider:

- This adds more files for CocoaPods support in the React Native repo, but it puts each one next to the Xcodeproj it represents.
- The "React Native repo as Specs repo" adds a folder called "Specs" in the root, which is confusing for JS/Android folk. We can add support into CocoaPods to recognize "Podspecs" instead also.
- If you were already separating your JS repo from your app code, then you would need to change your Podfile. But this means you don't have to host these Podspecs yourself (or [use Artsy's](https://github.com/artsy/specs))


## Alternatives

- CocoaPods support could be handled by [shipping binaries](https://github.com/react-native-community/discussions-and-proposals/issues/15) of React Native to clients. Personally, I prefer to be working with the source code for ease of forkability and debugging.

## Adoption strategy

Shouldn't be major, a paragraph or two in the blog post for the version that first supports it and an update to the docs page for integrating with an existing app.

## How we teach this

Shouldn't be an issue here.

## Unresolved questions

The biggest call is:

- Submitting the Podspecs to CocoaPods on a deploy, or
- Turning the "React Native repo into a Spec repo"

If anyone can talk to the original reasons for deprecating trunk support? then I can give a better opinion about which makes the most sense. The first one is simpler for everyone, but in 2016 the trunk support was [deprecated](http://cocoapods.org/pods/React).