feat: autolinking for iOS with CocoaPods

[alloy]

• Updates react-native config to include full paths to the root of packages. It is very feasible that in the future we may want to load a package from a different location than the standard project/node_modules/a_package location, so abstracting that away from the CocoaPods and Gradle code will keep those agnostic and centralise it in a single place.
• Imports the Ruby script that a Podfile will use to discover and add native module pods to the Podfile.
• Parses react-native config warnings from output and shows those as per CocoaPods’ UI rules.

---

This is what it currently looks like when ran:

[orta]

@alloy switch the CI to circleci/ruby:2.4-node

[brentvatne]

love it!

[orta]

I wonder if we need to be careful of accidentally importing something like

pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'	

Perhaps anything in third-party-podspecs is specifically knowns as using :podspec?

[grabbou]

Good catch!

[alloy]

@orta How would that happen? We require podspecs to be in the root of the native module repo to be picked up. Or are you saying we still need to support those vendored podspecs?

[orta]

Ah, so none of the React Podspecs would get found? (Maybe only the React root podspec? )

[alloy]

Yeah that’s what we discussed about native code in npm packages, in general. It’s a good question, though, I should look at what is actually being done in the RN repo with these vendored libraries. (Anyone got a link to a write-up?)

[brentvatne]

so with the unimodules script we decided to use a single config file, unimodule.json, so that discovery is very easy and we can add additional metadata when needed (right now it's just the name and platforms) discovery of native modules is then done through globbing node_modules (and other paths provided by the user where packages can exist) for this config file named unimodule.json.

i'm curious - why not use the same approach here? it'd resolve the issue that @orta mentioned above about accidentally including podspecs too.

[grabbou]

@brentvatne, we have decided to just reuse existing CLI configuration instead of adding a new JSON file. Our current infrastructure setup makes this super easy. We've been using this mechanism to power up existing "link" and while "link" itself has been working quite unstable recently, the metadata was the "good part" of it.

Right now, "link" command works by taking an array of dependencies that were discovered by the CLI. The discovery process itself is done by checking each of the direct project dependencies (listed explicitly in dependencies and devDependencies) whether they include an iOS project or Android project.

The format looks as follows:

{
   "react-native-camera": { "android": null, "ios": null }
}

in case no native files to link were found for supported platforms. The platform keys are dynamic and can contain e.g. "windows", when having "react-native-windows" installed.

As I said, android and ios keys can have either null values (no project for given platform to link) or be an object with metadata, used by link command to actually do its linking work.

Here's an example of metadata for iOS: https://github.com/react-native-community/react-native-cli/blob/master/packages/cli/src/tools/ios/index.js

Note that this gets much smaller with this new version.

This object, apart from platform keys, also contains an information about scripts to run as a part of build step, optional params that module accepts and hooks to run pre/post linking phase.

We do the processing in Javascript, on the CLI side, so that both Android and CocoaPods can take an object with metadata and just do their linking work.

The idea is to have an object similar to the following one:

{ dependencies: { "name": { "android": {}, "ios": {}}}

to be loaded with Cosmiconfig, so that you can define the configuration yourself when needed (create react-native.config.js) and override any key/value you want (we deep merge them - auto-detected settings are defaults and users can override them).

This makes it super easy to disable linking entirely (set to null) or update it when something is not working (override value for a given key).

Users can also provide additional projects here and just give paths to Podfile that are not inside node_modules but e.g. inside vendor in case they have a project that consists of multiple sub-projects and they want to link them.

So yeah, the approach is a bit more flexible and allows zero configuration at first. We will see how it evolves next week.

Let me know if you have any additional questions, ideally to follow up in #254.

[brentvatne]

hey @grabbou - thanks for the explanation! it's still not clear to me though why it is better to attempt to detect whether a project has ios/android dependencies rather than have the project say it explicitly though. also, i don't think it's exactly zero configuration, it's just that the configuration is implicit in some file structure that the cli detects.

[alloy]

(:ceiling-cat: I think this discussion makes a lot of sense, but agree that it should probably happen on #254. The whole reason we wanted the Android and iOS specific parts of the implementation to be agnostic of dependency discovery was so that these things could be discussed and implemented in the centralised ‘config’ part of the react-native CLI.)

[thymikee]

@alloy @orta ping, the #254 is done, so you should be good to continue working on this :)

[alloy]

Will rebase now 👍

[alloy]

Still left to do is adding an integration test to the JS test suite that invokes the Ruby tests with the latest config format, otherwise it will be too easy for people to make breaking changes to the JS side.

However, I’ll do so in a follow-up PR, I’d rather get this merged ASAP so we don’t run any further out of sync with master.

[grabbou]

@alloy - one more conflict and we are good to go. Do you feel like merging this and doing tests as a follow-up?

[grabbou]

What we can do is set this up in RNTester's CocoaPods integration on master to make sure that it actually works.

[alloy]

Will do 👍

That [integration test] sounds interesting, but wouldn’t that only bring breakage to light after having published a new version of the CLI package?

[grabbou]

@alloy, I am actually rebasing this for you already, so no action needed :)

[grabbou]

Merged in 76f079e

[grabbou]

Tests seem to be failing, could be related to rebasing: https://circleci.com/gh/react-native-community/cli/2999

Does this give you any idea?

[orta]

I think the test needs its string updating to include "React Native module" instead of just module

[grabbou]

Right, it's explicit. I am blind at this time of the day lol. Thanks!