[Dependencies] Module system (fantastic project for interested contributors!)

[ide]

Currently React Native ships with a set of modules, some of which are ubiquitous (basic View support) and some that are used only in a handful of apps (e.g. Vibration support). As the set of modules grows, the size of the 'react-native' JS will also increase and slow down the boot time for apps. There's already overhead on the order of a couple hundred milliseconds spinning up a JSContext and loading every single Obj-C class (#69) so reducing the startup cost is valuable. Also there needs to be a module system in place to support third-party components, especially those with a native implementation.

Features:

My current thinking is a good module system would let you:

• Pay for only what you use. Ex: if you don't use a database module then your app shouldn't include the JS for it (string loading + parsing + evaluation cost) nor the native binary code (app size cost).
• Dedupe native dependencies. This is a requirement since you cannot have two Obj-C classes with the same name. Ex: two modules may both use CocoaLumberjack, a very popular logging library. The module system should determine which version of CocoaLumberjack is compatible with both modules and download and link just one copy. Good news is that the CocoaPods system already does this with a constraint solver!
• Dedupe JS depedendencies. Many JS components will use the same npm modules. Unlike Node on the server (boot time is hidden from the user + powerful hardware available), extra JS on the client (esp. mobile clients) adds a user-facing cost. So . This is not a hard requirement unlike with the native dependencies, but still important.

Design:

The gist is that the modules should be hosted in npm and will include both a package.json and a podspec (similar in spirit to package.json but for Obj-C and Swift). The package manager client (that is, what this project is about) looks inside node_modules for React Native components and updates a Podfile to reference these modules. The rest of the work is delegated to CocoaPods:

File hierarchy:

Podfile
Autogenerated-npm-Podfile  # created by the tool
node_modules/
  react-native-page-view-controller/
    package.json
    index.js
    ios/
      RCTPageViewController.h
      RCTPageViewController.m
      react-native-page-view-controller.podspec

Podfile

# all your normal dependencies, here are some examples
pod 'AWSiOSSDKv2', '~> 2.1'
pod 'CocoaLumberjack', '~> 2.0'
pod 'FMDB', '~> 2.5'
pod 'GoogleAnalytics-iOS-SDK', '~> 3.0'
pod 'Reachability', '~> 3.2'

require 'Autogenerated-npm-Podfile'

Autogenerated-npm-Podfile

# @generated by hypothetical tool
# Reference the local pods that live in node_modules
pod 'react-native-page-view-controller', 'node_modules/react-native-page-view-controller/ios'

What the tool does:

1. Scans node_modules for the podspecs
2. Adds references to them in an autogenerated file that is loaded from the Podfile (Podfiles and Podspecs are just Ruby)
3. Runs pod install or pod update, whatever is appropriate

The workflow

npm install react-native-page-view-controller
cool_tool
# open App.xcworkspace

There are details to be worked through but I believe this is directionally correct.

Skill set:

Strong familiarity with npm and iOS development is helpful, as well as some familarity with CocoaPods. You could learn some of these as you go though you'll be more comfortable with an advance understanding of how the pieces fit together and what npm and CocoaPods can and can't do.

I'm happy to provide feedback, direction, or mentorship if someone or a pair of people want to take up this endeavor - it should be a worthwhile project that lots of people will use.

[tommymchugh]

I'll definitely take a stab at this. Something to think about is whether there should be a value for react-module in its package.json to let the manager know that it is a react module. That way, if a node module includes a podfile for other reasons, the react package manager won't try to add it as a dependency.

[ide]

@tommchugh Great to hear you're interested. I agree it makes sense for package.json to denote that the package is a React Native module for the reason you mentioned and also it could be useful to store extra metadata (ex: which platforms are supported).

[corymsmith]

I'm working on taking a crack at this right now, agree on a entry in package.json, was thinking about that as well.

[tommymchugh]

You can take a look at what I have right now: https://github.com/TomMcHugh/react-native/tree/extension-manager/react-extension-manager

Pretty rough and just threw it together in the past couple of hours, but so far it has the basic functionality.

[tommymchugh]

One thing that I found was that Podfiles aren't very friendly to using require. Might have to look into that. Because of that, I just inject the dependencies straight into the users Podfile.

[corymsmith]

Looks great, pretty much what I was just writing! Good call on injecting right into the podfile.

[tommymchugh]

Yeah, it's important it doesn't mess up a users Podfile. Thats why I have the rem init function create a commented out section where the package manager will look to inject the depenedency. It's a little hacky, but until we solidify whether we can do require on podfiles, it works.

[ide]

Perhaps eval instead of require is the right thing to do since the autogenerated file should have access to all of the functions that the main Podfile does. I believe this matches how CocoaPods loads the main Podfile in fact: https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/podfile.rb#L254

[tommymchugh]

Eval is what we're looking for. Just pushed it with some code restructuring changes to my forked branch. We now have a separate Podfile that is managed by the manager.