react-native bundle configs #14400

Description

This is a react-native bundle and react-native packager issue.

Currently there is no way of modifying the configurations passed to react-native bundle when building for iOS and Android. You are locked into the configs either the Debug/Release build config and build type respectively pass. Also, unlike what many recent posts about this might suggest about this issue, it seems you cannot just call react-native bundle ahead of the build with your params and have the native build pick that bundle up.

Reproduction Steps and Sample Code

Configs for bundling in an iOS build are essentially hardcoded in ./node_modules/react-native/packager/react-native-xcode.sh to scheme configuration set in Xcode. If you set the build type to debug, you have then set dev to true, and there is no way of making a debug build, signed with developer certs with an offline bundle. The same is true for the opposite. I have not yet found a way around this without changing react-native-xcode.sh or the bundle React Native build phase in Xcode.

Configs for Android are slightly easier to change if necessary, as ./android/app/build.gradle has the project.ext.react property list that can be configured. By setting bundleInDebug to true, we can create an unsigned debug release with the bundle embedded. The problem is this requires changing the build.gradle each time, or doing something like this:

if ( project.hasProperty("bundleInDebug") ) {
    project.ext.react = [
        bundleInDebug: true
    ]
}

and via Fastlane:

  gradle(
      task: "assemble",
      build_type: "Debug",
      project_dir: "android",
      properties: {
        "bundleInDebug" => true
      }
  )

or directly in gradle:

$PROJECT/android/gradlew assembleDebug -p android -PbundleInDebug=true

An example use case for this is internal alpha builds - where other developers or QA need a development build for debug access, not signed for release/appstore, and cannot be dependent upon a development server running. Hockeyapp is frequently used for this - distribution of these kinds of builds internally.

For beta builds that are a bit more open, the current configurations work fine and as intended for Testflight and Playstore beta.

Solution

There are a few possible solutions here, and I would be willing to make a PR for both better documentation and a new process, but would like input on what that process should be. This is clearly an issue, and I would like to see either how others have worked around it or solved it in the recent updates.

Solution 1:
We move the location of jsbundle to a predictable location (not derived data) allowing users to make a bundle however they choose ahead of the native build, and configure the native build to skip that particular build phase/step if that file is already present. We would also have to clean that folder at the end of a build. I believe this would be the easiest solution, but possibly the most breaking change.

Solution 2:
Keep the current order/flow of the native builds calling the bundle - Modify react-native-xcode.sh to allow for overriding properties passed in through xcargs and modify react.gradle to more easily accept property overrides from gradle. (this may already be possible through a better solution than above, as my understanding of groovy & gradle is not the best)

Solution 3:
Some combination of the above

Solution 4:
Tell me what I missed, because this isn't actually an issue, and close, and perhaps I should drink more coffee in the morning before submitting issues on GitHub.

Additional Information

• React Native version: 0.44
• Platform: iOS+Android
• Development Operating System: MacOS 10.12.4
• Dev tools: Xcode 8.3.2