[RFC] Distributing RN Android artifacts via npm instead of JCenter

[mkonicek]

I've been thinking about distributing the Android artifacts via npm instead of Maven Central, like it's done on iOS (we distribute source code there).

Having two separate systems makes things more complicated. How do people upgrade their app to a new version of React Native, for example? Currently, people have to update both:

package.json:

"dependencies": {
  "react-native": "0.11.4",
}

build.gradle: compile 'com.facebook.react:react-native:0.11.+'

Releasing would also become easier: just npm publish.

[mkonicek]

@ide I think you've proposed this too some time ago?

cc @foghina @kmagiera

[satya164]

If a module depends on a third party library from maven or jcenter, how is it handled?

[ide]

I'm in favor of using npm for distributing code and using a system like Buck or Gradle (fyi I'd be interested in trying Buck instead of Gradle) to set up the classpath and link the dependencies together. We do something similar with CocoaPods: instead of using the copy of React Native published to the CocoaPods repo, I point the CocoaPods tool at node_modules/react-native.

Would the dependencies like Fresco and JSC be included inside the react-native JAR? Or does Gradle know that react-native depends on those libraries, and then fetches them from JCenter / Maven?

[corbt]

@satya164 currently Android modules that are implemented using the strategy laid out by @chirag04 here are able to declare dependencies from maven central/jcenter and they are compiled just fine. Here's a random android RN library I found. You can see from its build.gradle that it depends on a couple of other Java libraries. This works because the module is designated as a subproject to the main Android app project, and Gradle recursively builds that project's dependencies as well.

Not totally sure though how that would work if one RN module with native Android code depends on another RN module with native Android code though, which is probably an important use case to support...

@ide mentioned switching to Buck as one possibility. As a sometimes Android developer I have no particular love for Gradle, and if this turns out to be an easier problem to solve with Buck because FB has control of its development, I don't think that would be a dealbreaker for most users. That being said, the fast-intermediate-build that seems to be Buck's biggest draw (for use outside FB) is much less interesting with RN projects because you have to rebuild so infrequently anyway. So if a Gradle plugin/config generator can do the job, that's probably better just from a familiarity point of view. This would be especially important in adding React Native to existing apps, which may already have a complex Gradle-based build process (although I don't know how much demand there will be for that in general -- I just know that I'm planning on moving a few things over in a piecemeal fashion).

[mkonicek]

Hi there! This issue is being closed because it has been inactive for a while.

But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/rfc-distributing-rn-android-artifacts-via-npm-instead-of-jcenter

ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.

Also, if this issue is a bug, please consider sending a PR with a fix. We rely on the community to provide
bugfixes as the core team is focused on performance.