Summary:This small update to runAndroid.js allows to specify product flavor as optional argument, like that:
`react-native run-android --option-flavor=staging`
This option is useful when developing complex applications that require some flavor-specific functionality. More information about productFlavors can be found here: http://developer.android.com/intl/ru/tools/building/configuring-gradle.html
Closes https://github.com/facebook/react-native/pull/6010
Differential Revision: D3011662
Pulled By: mkonicek
fb-gh-sync-id: ce730a17340c1f21b5d75f28a784db4d6fd99725
shipit-source-id: ce730a17340c1f21b5d75f28a784db4d6fd99725
Summary:Shelling out on win32 does not properly escape the command due to https://github.com/nodejs/node/blob/c3bb4b1aa5e907d489619fb43d233c3336bfc03d/lib/child_
This patch ensures a proper lineNumber before continuing, similar to how we check that the fileName passed exists.
**Test plan**
On platform `win32` or given appropriate testing changes to `launchEditor.js`...
With the following `request-bad` file:
```
GET /open-stack-frame HTTP/1.1
Host: 127.0.0.1:8081
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Content-Length: 64
{"file":"C:\\Windows\\system.ini","lineNumber":"123\" && calc"}
```
`$ nc localhost 8081 < request-bad`
Observe that before this patch `calc` would launch and afte
Closes https://github.com/facebook/react-native/pull/6299
Differential Revision: D3012074
Pulled By: davidaurelio
fb-gh-sync-id: cbc7b6e5c60529a289c0989a95593a322333ba5d
shipit-source-id: cbc7b6e5c60529a289c0989a95593a322333ba5d
Summary:In order to be able to Hot Load Redux stores and modules that export functions, we need to build infrastructure to bubble up the HMR updates similar to how webpack does: https://webpack.github.io/docs/hot-module-replacement-with-webpack.html.
In here we introduce the minimum of this infrastructure we need to make this work. The Packager server needs to send the inverse dependencies to the HMR runtime that runs on the client so that it can bubble up the patches if they cannot be self accepted by the module that was changed.
This diff relies on https://github.com/facebook/node-haste/pull/40/files which adds support for getting the inverse dependencies.
Reviewed By: davidaurelio
Differential Revision: D2950662
fb-gh-sync-id: 26dcd4aa15da76a727026a9d7ee06e7ae4d22eaa
shipit-source-id: 26dcd4aa15da76a727026a9d7ee06e7ae4d22eaa
Summary:We've received reports saying that sometimes HRM updates take a couple of seconds to get applied. The feature is very optimized so that it takes around 100ms for most common type of changes. Only changes that require rebuilding caches could take longer than that, maybe up to 1 second.
We think the problem is that watchman delays sending the file change notification because the system is under heavy use. It worth mentioning this is not a watchman issue!. This could happen for instance if flow is enabled. So, to better understand what's going on lets log when a file is changed and just before sending the HMR update to the client. The client codepath is extremelly fast so no need to log any of that.
Reviewed By: davidaurelio
Differential Revision: D2978694
fb-gh-sync-id: abd3b473d0b7ac7cd4461effce9813ccfda32c2b
shipit-source-id: abd3b473d0b7ac7cd4461effce9813ccfda32c2b
Summary:If jsBundleDir variable was defined, then RN image assets would be
thrown into the assets folder along with the js bundle. This is a
bug. Image assets should be published into a different folder than the
js bundle.
A new variable resourcesDir is defined where RN image assets and the
like should be published into.
Closes https://github.com/facebook/react-native/pull/5828
Differential Revision: D2980235
Pulled By: mkonicek
fb-gh-sync-id: af913814e2fcce42aaa1fbed2a68fd719198f306
shipit-source-id: af913814e2fcce42aaa1fbed2a68fd719198f306
Summary:**Problem**: As seen in https://github.com/facebook/react-native/issues/5820, many devs are confused by the fact that the offline bundle is not generated when running against the simulator, even when running in the "Release" configuration which is supposed to mimic "production" scenarios.
This pull request is a small change that fixes https://github.com/facebook/react-native/issues/5820 by updating the `react-native-xcode.sh` shell script to still generate the ofline bundle during Release configuration. It also updates `AppDelegate.m` to better document this behaviour in the comments so as to avoid any surprises.
**Test plan**: This is a simple change, the two tests done were
1. In a new React Native project, verify that an offline build is not generated when running against the simulator in "Debug" configuration as per normal.
2. Change to a "Release" configuration via Product > Scheme > Edit Scheme in XCode, then verify that the project runs with the offline build generated.
![screen shot 2016-02
Closes https://github.com/facebook/react-native/pull/6119
Differential Revision: D2970755
Pulled By: javache
fb-gh-sync-id: 64f658512869c73aa19286ca1e3dc6e31b5ac617
shipit-source-id: 64f658512869c73aa19286ca1e3dc6e31b5ac617
Summary:Added a `root` option to the `run-android` command allowing to run it from a parent directory.
Use case: project is organized like this
```
- api
- apps
---- web
---- react-native
- package.json
```
You can use the root option on `react-native start` but not on `run-android`. This pr fixes that.
Closes https://github.com/facebook/react-native/pull/5597
Differential Revision: D2959523
Pulled By: mkonicek
fb-gh-sync-id: 03fb74b201fe9e89bf6fab80c9a98ca708464261
shipit-source-id: 03fb74b201fe9e89bf6fab80c9a98ca708464261
Summary:
This PR moves `react` from dependencies to peerDependencies.
In general, this would have only been important for those people using packages that depend on `react` and were using [email protected]@3 would automatically de-dupe.
However, when #5812 gets merged, dependencies will be scoped to react-native (on both npm@2 & npm@3), thus breaking projects that are using a package like `react-redux` for example, which depends on `react`. There would be two copies of React installed, and due to the use of haste modules in `react`, this would break the packager and cause naming collisions.
This PR does three things -
1. Moves the dependency from dependencies to peerDependencies
2. Updates the local-cli to run `npm install react --save` when a new project is initialized.
3. Updates `react-native upgrade` to warn if `react` is not listed in the package.json's dependencies.
**Note: This will require a shrinkwrap update.**
Closes https://github.com/facebook/react-native/pull/5813
Reviewed By: svcscm
Differential Revision: D2918380
Pulled By: androidtrunkagent
fb-gh-sync-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486
shipit-source-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486
Summary:
This lets us say goodbye to Maven Central. This will greatly simplify
and speed up the release process as releasing Android artifacts to
Maven Central adds a lot of [complexity](https://github.com/facebook/react-native/blob/master/Releases-publish.md)
and delays the whole release by several hours when we have to wait
for the artifacts to propagate.
This diff assumes there's a local Maven repo at
`node_modules/react-native/android`.
The second part once this lands is to change our `release.sh` script to
output the artifacts under `react-native/android` before publishing to
npm.
This adds 3.7MB to the size of `node_modules` of any app. However,
we just download eagerly what we'd normally download later via Gradle.
**Test plan**
Released RN including a local Maven repo into Sinopia:
$ cd react-native
# Updated version in gradle.properties to 0.21.0
$ ./gradlew ReactAndroid:installArchives
# Moved everything in .m2/repository/com/facebook/react to react-native/android
$ ls react-native/android
com/facebook/react/react-native/0.21.0/react-native-0.21.0.aar
com/facebook/react/react-native/0.21.0/react-native-0.21.0.pom
com/facebook/react/react-native/maven-metadata.xml
...
# Set version in package.json to 0.21.0
$ npm set registry http://localhost:4873/
$ npm publish
Created and ran an app:
$ cd /tmp
$ react-native init AndroidNpm
$ cd AndroidNpm
$ react-native run-android
It worked.
Checked that we're using the artifacts from node_modules/react-native/android:
$ cd android
$ ./gradlew app:dependencies
compile - Classpath for compiling the main sources.
+--- com.android.support:appcompat-v7:23.0.1
| \--- com.android.support:support-v4:23.0.1
| \--- com.android.support:support-annotations:23.0.1
\--- com.facebook.react:react-native:+ -> 0.21.0
+--- com.google.code.findbugs:jsr305:3.0.0
+--- com.facebook.stetho:stetho-okhttp:1.2.0
...
Checked that Android Studio can find the source jars (you can navigate to RN sources in Android Studio). Opened the new project as described in the [docs](https://facebook.github.io/react-native/docs/android-setup.html#editing-your-app-s-java-code-in-android-studio).
public
Reviewed By: bestander
Differential Revision: D2912557
fb-gh-sync-id: 251c180518a3fb9bb8e80963b236e982d65533be
shipit-source-id: 251c180518a3fb9bb8e80963b236e982d65533be
Summary:
We should use 4 spaces of indentation in the MainActivity template as this
is the most common setting outside fb.
public
Reviewed By: bestander
Differential Revision: D2911952
fb-gh-sync-id: 3b5285945f0033d7342348b7a7cbafa32809f7dc
shipit-source-id: 3b5285945f0033d7342348b7a7cbafa32809f7dc
Summary:
The bundler class had duplicated code and parts that were hard to follow, because functions accepted heterogenous arguments, leading to a lot of conditionals.
This commit tries to remove duplication between build steps of different type of bundles, and by accepting less different types of arguments. These differences are now handled further up the call stack.
public
Reviewed By: sebmarkbage
Differential Revision: D2905807
fb-gh-sync-id: ef85ea0d461a9a06a4a64480e014a5324c4ef532
Summary:
- Capitalise productFlavorName for target path
- Capitalise buildType in sourceName when flavour exists
- Fix the path the assets are added.
- Backward compatibility with bundleIn(buildTypeName) when flavours are added
Closes https://github.com/facebook/react-native/pull/5580
Reviewed By: svcscm
Differential Revision: D2911735
Pulled By: mkonicek
fb-gh-sync-id: 6fb391a12ee27ee2a503961d8779a85d31cf5367
Summary:
until we have an automated test in CI
Closes https://github.com/facebook/react-native/pull/5775
Reviewed By: svcscm
Differential Revision: D2911639
Pulled By: mkonicek
fb-gh-sync-id: 26d8194dd5a6fd7210f4b014787e6847217dd7f1
Summary:
`debugger.html` contained a ton of hacky code that was needed to ensure we have a clean JS runtime every time a client RN app connects. That was needed because we used the page's global environment as runtime. Some time ago WebWorker support was added and now we run RN code inside an isolated WebWorker instance, and we can safely get rid of all these hacks.
This has a bunch of nice side-effects: debug reload works faster, `console.log`s are preserved, `debuggerWorker.js` selection doesn't change.
Made sure the debugging (breakpoints, etc.) still works as before.
Small demo
Closes https://github.com/facebook/react-native/pull/5715
Reviewed By: svcscm
Differential Revision: D2906602
Pulled By: frantic
fb-gh-sync-id: 1a6ab9a5655d7c32ddd23619564e59c377b53a35
Summary:
ReactProp and ReactPropGroup were moved in the annotations package but the proguard file was not updated accordingly. This caused apps to crash when built in release using proguard.
Fixes#5655
Closes https://github.com/facebook/react-native/pull/5717
Reviewed By: svcscm
Differential Revision: D2905573
Pulled By: lexs
fb-gh-sync-id: 29ab14bacda7254d9896ff3991bf17d7fdfd6ea9
Summary:
React dev tools have been broken since we moved to web worker but we had a gigantic upsell for them. This must be a very frustrating experience for people just starting to use react native to be told to use something and see that it doesn't work.
Removing that upsell until it works again
<img width="1090" alt="screen shot 2016-02-04 at 2 00 37 pm" src="https://cloud.githubusercontent.com/assets/197597/12831501/8eba3f4e-cb49-11e5-8bdc-84f902053321.png">
Closes https://github.com/facebook/react-native/pull/5768
Reviewed By: svcscm
Differential Revision: D2903017
Pulled By: vjeux
fb-gh-sync-id: 731c5fefbef1a5249d632fc62ca36813533f2639
Summary:
public
The packager currently assumes that all assets that are not JSON or JS files must be images. Although it is possible to add other extension types, they crash the packager if you try to require them, because it attempts to get their dimensions, assuming that they are an image.
This is a crude workaround for that problem, which skips the image-specific processing for non-image assets, but really it would be better if the packager was properly aware of different asset types and treated them differently (e.g. for sounds it could include the duration, for HTML pages it could parse and include linked CSS files, etc).
I've also added an example of using `require('...')` to load a packager-managed HTML page in the UIExplorer WebView example. In future I anticipate that all static asset types (sounds, fonts, etc.) could be handled in this way, which allows them to be edited or added/removed on the fly instead of needing to restart the app.
Reviewed By: martinbigio
Differential Revision: D2895619
fb-gh-sync-id: cd93794ca66bad838621cd7df3ff3c62b5645e85
Summary:
public
Introduce a header bar similar to the one shown when loading the bundle to indicate that the packager server is processing an HMR update. Hook into HMR events to show this bar when appropriate.
Reviewed By: javache
Differential Revision: D2873521
fb-gh-sync-id: a77cbb2368b75b045aa8c6ababce2f731baf514b
Summary:
public
The HMR listener needs to be invoked on the non debounced callback to avoid loosing updates if 2 files are updated within the debounce configured time.
Also, improve the time it takes to send HMR updates by avoiding rebuilding the bundle when the listener is defined. Instead just invalidate the bundles cache so that if the user reloads or disables Hot Loading the packager rebuilds the requested bundle.
Reviewed By: davidaurelio
Differential Revision: D2863141
fb-gh-sync-id: 3ab500eacbd4a2e4b63619755e5eabf8afdd1db9
Summary:
public
At the moment, when the user changes a file we end up pulling the dependencies of the entry point to build the bundle. This could take a long time if the bundle is big. To avoid it, lets introduce a new parameter to `getDependencies` to be able to avoid processing the modules recursively and reuse the resolution responseto build the bundle.
Reviewed By: davidaurelio
Differential Revision: D2862850
fb-gh-sync-id: b8ae2b811a8ae9aec5612f9655d1c762671ce730
Summary:
public
To make sourcemaps work on Hot Loading work, we'll need to be able to serve them for each module that is dynamically replaced. To do so we introduced a new parameter to the bundler, namely `entryModuleOnly` to decide whether or not to process the full dependency tree or just the module associated to the entry file. Also we need to add `//sourceMappingURL` to the HMR updates so that in case of an error the runtime retrieves the sourcemaps for the file on which an error occurred from the server.
Finally, we need to refactor a bit how we load the HMR updates into JSC. Unfortunately, if the code is eval'ed when an error is thrown, the line and column number are missing. This is a bug/missing feature in JSC. To walkaround the issue we need to eval the code on native. This adds a bit of complexity to HMR as for both platforms we'll have to have a thin module to inject code but I don't see any other alternative. when debugging this is not needed as Chrome supports sourceMappingURLs on eval'ed code
Reviewed By: javache
Differential Revision: D2841788
fb-gh-sync-id: ad9370d26894527a151cea722463e694c670227e
Summary:
public
This adds the ability to load “unbundles” in RN android apps. Unbundles are created by invoking the packager with the `unbundle` command rather than `bundle`.
The code detects usage of an “unbundle” by checking for the existence of a specific asset.
Reviewed By: astreet
Differential Revision: D2739596
fb-gh-sync-id: d0813c003fe0fa7b47798b970f56707079bfa5d7
Summary:
public
When we were debugging in the main window JS context in Chrome, the global environment had to be tweaked so that DOM features wouldn’t be detected.
Since we switched to debugging within a web worker, we don’t need to do this tweaks any more.
Reviewed By: bestander
Differential Revision: D2850239
fb-gh-sync-id: 886f2f7ac5c579c3fd4a424d5341bc6bc0432c0d
Summary:
Now packager only listen to "::", which is IPv6 "Any address".
It failed to run in IPv4 Environment.
defaults to undefined or empty string will fix this.
And I think it's necessary to let user define host by cli argument.
It's also for security reason. When working on a public network, it's much safer to listen with localhost instead of ::, which may let everyone in same network be able to get your code from debugger-ui.
recommit for #1918, fixes#2441
Closes https://github.com/facebook/react-native/pull/5377
Reviewed By: svcscm
Differential Revision: D2842594
Pulled By: martinbigio
fb-gh-sync-id: 575944c5469dac80e99136a7903ea99f5339dba1
Summary:
public
- Tweak OSS server to enable the HMR connection
- Remove client gating code.
- Resolve internal transforms plugins
After this diff, Hot Loading should work on OSS.
Reviewed By: javache
Differential Revision: D2803620
fb-gh-sync-id: b678180c884d2bfaf454edf9e7abe6b3b3b32ebe
Summary:
Currently, the CLI is not passing the sourceMapURL option to the bundler, so source maps are output as "null".
Closes https://github.com/facebook/react-native/pull/5288
Reviewed By: svcscm
Differential Revision: D2828092
Pulled By: androidtrunkagent
fb-gh-sync-id: 2e464ddf65f0d4fcbff3c50281391cb30b5c799c
It caused problems on Windows unfortunately and when we tried to
fix it we got: https://github.com/facebook/react-native/issues/5159
Reverting to unblock people. In the future we'll do careful rc
releases of the CLI. We should try to make the change again without
breaking anyone, regardless of OS (OSX, Linux, Windows) or npm version.
Summary:
This PR adds support for Android Gradle [Build Variants](https://sites.google.com/a/android.com/tools/tech-docs/new-build-system/user-guide#TOC-Build-Variants) when generating the JS bundle.
**Before**: only supported "bundleDebugJsAndAssets" and "bundleReleaseJsAndAssets"
**Now**: all variants are supported
Examples: "bundleDevDebugJsAndAssets", "bundleStageAlphaJsAndAssets", or "bundleBetaJsAndAssets"
The Gradle script will automatically create bundle tasks for each build variant found in a project.
Closes https://github.com/facebook/react-native/pull/4686
Reviewed By: svcscm
Differential Revision: D2815856
Pulled By: foghina
fb-gh-sync-id: 4518de70d178205bc3e5044d2446b56c40298da2
Summary:
public
We should further improve this on the future by showing the actual stacktrace instead of the `HMRClient` one. Also, we need to integrate this with the dev plugin that opens in the default editor the file/line the user clicks on.
Reviewed By: vjeux
Differential Revision: D2798889
fb-gh-sync-id: 2392966908c493e86e11b0d024e7b68156c9066c
Reviewed By: mkonicek
Differential Revision:D2812482
Ninja: Doesn't affect any fb apps or code, purely for open source
fb-gh-sync-id: 4d190354112e3f002405686769dcc409e3394c3c
Summary:
public
Fixes a terrible bug due to which when Hot Loading enabled when the user reloads we'll serve them the first `hot` bundle he requested. This happened because when HMR enabled we bailed out after sending the HMR updates and didn't rebuild any of the bundles the user requested before. As a consequence, when they reload we'd sent him the first and only one we ever built.
The fix is to tweak the hmr listener to return a promise. This way we can run the remaining code on the file change listener just after the HMR stuff finishes. We need to do it this way to avoid the remaining stuff to compete for CPU with the HMR one and give the best possible experience when HMR is enabled.
Reviewed By: davidaurelio
Differential Revision: D2811382
fb-gh-sync-id: 906932d71f35467485cf8a865a8d59f4d2ff41a0
Summary:
This allows everyone to deploy significantly smaller APKs to they Play Store by building separate APKs for ARM, x86 architectures.
For a simple app, a release APK minified with Produard:
- Universal APK is **7MB**
- x86 APK is **4.6MB** (34% reduction)
- ARM APK is **3.7MB** (47% reduction)
Created a sample project, uncommented `// include "armeabi-v7a", 'x86'`:
cd android
./gradlew assembleDebug
Three APKs were created, unzipped each: one has only x86 binaries,
one has ARM binaries, one has both.
./gradlew assembleRelease
Three APKs were created, JS bundle is correcly added to assets.
react-native run-android
The correct APK is installed on the emulator and the app runs fine
(Gradle output: "Installing APK 'app-x86-debug.apk'").
With the line commented out the behavior is exactly the same as before,
only one universal APK is built.
Checked that version codes are set correctly as described in
http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splitshttp://developer.android.com/intl/ru/google/play/publishing/multiple-apks.html
Closes https://github.com/facebook/react-native/pull/5160
Reviewed By: svcscm
Differential Revision: D2811443
Pulled By: mkonicek
fb-gh-sync-id: 97b22b9cd567e53b8adac36669b90768458b7a55
Summary:
public
We're not planning to accept file removals in the short term on the HMR interface so lets bail when a file is removed (before this this we were throwing when trying to get the shallow dependencies).
Reviewed By: yungsters
Differential Revision: D2810534
fb-gh-sync-id: f2733382f4a2619e22bdf1163aa4180694fff9f8
To release a new version with the fix for Windows:
https://github.com/facebook/react-native/pull/5171
Thanks a lot @tdzl2003!
Tweaked the platform check to use `process.platform`
as that's more common in the codebase. No strong preference,
just for consistency.
Alexandr Pantyuhov
