[Android] How to publish custom modules for android.

[chirag04]

Currently npm and cocopod is just for publishing custom mdules for ios. Let's document the best way for android also.

keeping this as a tracking issue for the known issue(http://facebook.github.io/react-native/docs/known-issues.html#content)

cc @brentvatne @ide @mkonicek

[foghina]

Right now you can publish native code to maven central / jcenter and JS code to npm, and simply ask users to add both to their apps. This is not ideal and in the future we might want to look at a unified dependency system. One such system that I can imagine is have developers still publish separately to npm / maven / cocoapods, but in their package.json specify the maven and cocoapods dependencies. So when a user adds that dependency to their npm project we pick it up and automatically add the maven and cocopods deps to android and iOS. WDYT?

[foghina]

That would also require us to write code that picks up new native modules / views from added dependencies. Right now you have to manually add those to your CatalystInstance on Android, not sure how it works on iOS, but I'm guessing it's similar.

[chirag04]

I'm probably not the best person to answer this coz i don't have much experience with cocoapods/jcenter.

From past experience, npm worked really well for ios modules and then manually drag and drop to xcode project(one time task/not after every npm install).

[chirag04]

Having to distribute on npm / jcenter / cocoapods would be really annoying. If we can leverage npm for android then i think we could use npm as the unified solution.

[ide]

Currently I'm in favor of npm for distribution and cocoapods/gradle for linking.

[chirag04]

@foghina @ide Since we can link to local jar files in build.gradle, how about using npm for publishing and then just linking the jar file in build.gradle. This means developer can ship the jar to npm.

Refer:
http://stackoverflow.com/questions/20700053/how-to-add-local-jar-file-dependency-to-build-gradle-file

[ide]

I think there are two things we lose from the JAR:

• It's more complex to publish code
• It's harder to solicit PRs since people wanting to modify source now need to use a different setup

As a general engineering principle I'd rather things be fast and push caching as low as possible, where it makes sense. In this case if we could always build from source and tell gradle/javac to be smart when the lib source files haven't changed I think that'd be much better.

[chirag04]

I see what you mean and def agree to it. I just published react-native-mail and tried to npm install and use it in a project.

Here is what i had to do:

1. in android -> app -> build.gradle add compile project(':RNMail') as dependency.
2. in android -> settings.gradle -> add RNMail like this:

rootProject.name = 'AwesomeProject'

include ':RNMail', ':app'

project(':RNMail').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-mail/android')

Seems like npm is a good option.

cc @ide @foghina

[skevy]

@ide @chirag04 plus 1 to distributing over NPM. I think it's been working relatively well for iOS packages...and @chirag04 if there really is only 3 lines to get something installed into an Android project (or at least 3 lines for simple packages), seems like we have a winner :)

I also think that linking external packages might be something that react-native-cli could help with down the road.

[corbt]

So I think it should be possible to use a custom gradle plugin to add files to the classpath. That plugin could then walk the node_modules tree and add any dependencies with an android directory to the classpath. It might even be possible to add them as separate projects, which should lead to them only being recompiled when a file has changed.

If that doesn't work, it should definitely be possible to create an autogenerated react-native.gradle configuration file that includes the configuration inputs @chirag04 mentioned above, that's maybe regenerated every time a user calls react-native run-android (or even potentially on an npm install hook).

I 100% do believe though that Android dependencies should be distributed through npm, and ideally as uncompiled code as @ide said. The barrier to entry for component maintainers is many times higher if they have to publish to both maven and npm, and there's also a lot of potential confusion for users if they need to keep their package.json and build.gradle in sync.

[chirag04]

@ide @foghina @skevy One quick problem with the npm approach is peerDependencies.

I'm not sure how to handle peerDependencies in build.gradle. One simply cannot leave out the react-native dependency in build.gradle unlike js modules.

[mkonicek]

Sorry for the delay on this. I agree that distributing Java sources via npm is the easiest way for contributors. People are already doing that and modules that contain Java code even have a little Android icon at React.parts.

Since we all agree, let's say this part is decided :)

Now we just need to figure out an easy way to consume the modules. I haven't had time to look into this yet but @chirag04's approach looks good. We could just include that in all projects generated by react-native init. This can be done here: https://github.com/facebook/react-native/blob/master/local-cli/generator-android/templates/src/app/build.gradle