Summary:Main goal is to get this passed for OSX. I assume this works for linux; please verify. Also if specs need to be added, please suggest
an implementation as there is no __test__ dir for andriod.
using yargs (already a dependency) to allow other terminals besides OSX crummy default terminal. Like (iterm) :)
main use case:
` react-native run-android --open iterm`
The nice thing about this in ITERM is it opens another tab by default which is way less intrusive then OSX default term.
Closes https://github.com/facebook/react-native/pull/5232
Differential Revision: D3011590
Pulled By: mkonicek
fb-gh-sync-id: 7e2a004b3018b4d70aafadf4e9be9682561d7919
shipit-source-id: 7e2a004b3018b4d70aafadf4e9be9682561d7919
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 c3bb4b1aa5/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.
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
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
Summary:
public
We want to support Hot Loading on the packager itself instead of on the transformer. This will allow us to enable it on OSS (and for any scripting language, yay!).
For now to enable Hot Loading the packager's internals transforms need to be manually enabled (start packager with `--enable-internal-transforms`). I think the internal pipeline should always be enabled as it doesn't affect performance if there're no transforms and the user can disable Hot Loading through the setting on the app though. I'll tweak this on a follow up commit.
Reviewed By: vjeux
Differential Revision: D2801343
fb-gh-sync-id: 563984d77b10c3925fda6fd5616b814cdbea2c66
Summary:
public
Requires are transformed when building the bundle but we forgot doing so when building the HMR one.
Reviewed By: vjeux
Differential Revision: D2801319
fb-gh-sync-id: ae70612945ab81a05154b14d6b756ef390770542
Summary:
https://github.com/facebook/react-native/issues/3679 was only partially fixed as the behaviour only works on iOS. This implements the same behaviour for Android. If the JSBundle was loaded from the assets folder, this will load images from the built-in resources. Else, load the image from the same folder as the JS bundle.
EDIT: For added clarity:
On iOS,
Bundle Location: 'file:///Path/To/Sample.app/main.bundle'
httpServerLocation: '/assets/module/a/'
Name: 'logo'
type: 'png'
**Resolved Asset location: '/Path/To/Sample.app/assets/module/a/logo.png'**
On Android,
Bundle Location: 'file:///sdcard/Path/To/main.bundle'
httpServerLocation: '/assets/module/a/',
name: 'logo'
type: 'png'
**Resolved Asset location: 'file:///sdcard/Path/To/drawable_mdpi/module_a_logo.png'**
Closes https://github.com/facebook/react-native/pull/4527
Reviewed By: svcscm
Differential Revision: D2788005
Pulled By: mkonicek
fb-gh-sync-id: 3f6462a7ee6370a92dd6727ac422c5de346c3ff1
Summary:
Works the same way as `react-native run-android`, but targets iOS simulator instead. Under the hood, it uses `xcodebuild` to compile the app and store it in `ios/build` folder, then triggers `instruments` and `simctl` to install and launch the app on simulator.
Since Facebook relies on BUCK to build and run iOS app, we probably won't use `run-ios` internally. That's why I'm putting this as public PR instead of internal diff.
To test this, I hacked global `react-native` script to install react native from my local checkout instead of from npm, cd into the folder and ran `react-native run-ios`.
Closes https://github.com/facebook/react-native/pull/5119
Reviewed By: svcscm
Differential Revision: D2805199
Pulled By: frantic
fb-gh-sync-id: 423a45ba885cb5e48a16ac22095d757d8cca7e37
Summary:
When used in automation, `wrong-react-native` can cause problems because it does not
report the issue via exit code.
Closes https://github.com/facebook/react-native/pull/5114
Reviewed By: svcscm
Differential Revision: D2799995
Pulled By: frantic
fb-gh-sync-id: 23c32dac9b0fcdbeaf48b94e9cb220c6c1b344aa
Summary:
public
Before this diff we were only accepting the module that was modified but the user. This works fine as long as the user doesn't modify the dependencies a module has but once he starts doing so the HMR runtime may fail when updating modules' code because they might might a few dependencies. For instance, if the user changes the `src` a `Image` has to reference an image (using the new asset system) that wasn't on the original bundle the user will get a red box. This diff addresses this by diffing the modules the app currently has with the new ones it should have and including all of them on the HMR update. Note this diffing is only done when the we realize the module that was modified changed it's dependencies so there's no additional overhead on this change.
Reviewed By: vjeux
Differential Revision: D2796325
fb-gh-sync-id: cac95f2e995310634c221bbbb09d9f3e7bc03e8d
Summary:
public
This diff introduces an internal transforms pipeline that integrates with the external one. This has been a feature we've been looking to implement for a long time to use babel instead of `replace` with regexps on many parts of the packager.
Also, to split the bundle we'll need to run one transform. Internally for Facebook we can run the system-import transform altogether withe the other ones. For OSS we offer `transformer.js` which people can use out of the box if they're writing ES6 code. For those people, `transformer.js` will also run the internal transforms`. However they might want to tune the transforms, or even write the code on another language that compiles to Javascript and use a complete different transformer. On those cases we'll need to run the external transforms first and pipe the output through the internal transforms. Note that the order it's important as the internal transforms assume the code is written in JS, though the original code could be on other scripting languages (CoffeeScript, TypeScript, etc).
Reviewed By: davidaurelio
Differential Revision: D2725109
fb-gh-sync-id: d764e209c78743419c4cb97068495c771372ab90
Summary:
public
Before this this when a file was changed besides sending the HMR update we rebuild every single bundle that the packager had build (to serve it faster when the user hit cmd+r). Since when hot loading is enabled we don't do cmd+r all this work was pointless (except for when you're developing multiple apps using the same packager instance at the same time, which we can assume is very uncommon). As a consequence, the HMR update was competing with the rebundling job making HMR quite slow (i.e.: on one huge internal app it took up to 6s for the HMR changes to get applied).
So, this diff tweaks the file change listener so that we don't rebundle nor invoke the fileWatchers (use for live reload which is also useless when hot load is enabled) when hot loading is enabled. Also, it makes the HMR listener more high pri than the other listeners so that the HMR dev experience is as good as it can get.
Reviewed By: vjeux
Differential Revision: D2793827
fb-gh-sync-id: 724930db9f44974c15ad3f562910b0885e44efde
Summary:
public
Compute the dependencies of the bundle entry file just before sending HMR updates. In case the file that was changed doesn't belong to the bundle bail.
Reviewed By: vjeux
Differential Revision: D2793736
fb-gh-sync-id: f858e71b0dd5fe4f5b2307a22c6cef627eb66a22
Summary:
public
Implement all the necessary glue code for several diffs submitted before to get Hot Loading work end to end:
- Simplify `HMRClient`: we don't need to make it stateful allowing to enable and disable it because both when we enable and disable the interface we need to reload the bundle.
- On the native side we introduced a singleton to process the bundle URL. This new class might alter the url to include the `hot` attribute. I'm not 100% sure this is the best way to implement this but we cannot use `CTLSettings` for this as it's are not available on oss and I didn't want to contaminate `RCTBridge` with something specific to hot loading. Also, we could potentially use this processor for other things in the future. Please let me know if you don't like this approach or you have a better idea :).
- Use this processor to alter the default bundle URL and request a `hot` bundle when hot loading is enabled. Also make sure to enable the HMR interface when the client activates it on the dev menu.
- Add packager `hot` option.
- Include gaeron's `react-transform` on Facebook's JS transformer.
The current implementation couples a bit React Native to this feature because `react-transform-hmr` is required on `InitializeJavaScriptAppEngine`. Ideally, the packager should accept an additional list of requires and include them on the bundle among all their dependencies. Note this is not the same as the option `runBeforeMainModule` as that one only adds a require to the provided module but doesn't include all the dependencies that module amy have that the entry point doesn't. I'll address this in a follow up task to enable asap hot loading (9536142)
I had to remove 2 `.babelrc` files from `react-proxy` and `react-deep-force-update`. There's an internal task for fixing the underlaying issue to avoid doing this horrible hack (t9515889).
Reviewed By: vjeux
Differential Revision: D2790806
fb-gh-sync-id: d4b78a2acfa071d6b3accc2e6716ef5611ad4fda
Summary:
public
This diff adds infra to both the Packager and the running app to have a WebSocket based connection between them. This connection is toggled by a new dev menu item, namely `Enable/Disable Hot Loading`.
Reviewed By: vjeux
Differential Revision: D2787621
fb-gh-sync-id: d1dee769348e4830c28782e7b650d025f2b3a786
Summary:
I don't know the reasons, why the templates are written with the `react.createClass`method. Today I see lot's of examples using the **ES6 way**. In my own projects I'm using this way, too.
I removed `use strict`, since *Module code is always strict mode code*, according to the [spec](http://www.ecma-international.org/ecma-262/6.0/#sec-strict-mode-code).
Maybe we should **discuss** the usage of ES6 in the templates.
Closes https://github.com/facebook/react-native/pull/4891
Reviewed By: svcscm
Differential Revision: D2789493
Pulled By: androidtrunkagent
fb-gh-sync-id: 90e70f787017c61dc64cbc9f0beb02331fa749ec
Summary:
Passing around a `getTransformOptions` function doesn't really work with the CLI utils, so I'm changing this to `getTransformOptionsModulePath` instead, which can easily be injected in through `rn-cli.config.js`.
public
Reviewed By: martinbigio
Differential Revision: D2785789
fb-gh-sync-id: c9fdc358cb5d0db27e0d02496e44c013c77f3d5f
Summary:
Here are some small fixes for issues we've encountered with very large RN projects (mostly huge dependency trees in `node_modules`).
cc amasad martinbigio
Closes https://github.com/facebook/react-native/pull/4880
Reviewed By: svcscm
Differential Revision: D2782834
Pulled By: mkonicek
fb-gh-sync-id: e316a62b84ba796b80ac819431414ebf27f7b566
Summary:
Having a base activity allows us to add new features and fixes without having to change the generated `MainActivity` file.
cc mkonicek arbesfeld
Closes https://github.com/facebook/react-native/pull/4827
Reviewed By: bestander
Differential Revision: D2783527
Pulled By: mkonicek
fb-gh-sync-id: 707b82839809ca2e1775f5d3ac022a6d00bcac5a
Summary:
We decided to use different storage formats for android and ios. This diff changes the output format to asset files if the platform is `'android'`.
public
Reviewed By: martinbigio
Differential Revision: D2764739
fb-gh-sync-id: 4a5ac13ba7978112e9424573643e90cef2a1b75f
Summary:
The JavaScript ecosystem doesn't have the notion of a built-in native module loader. Even Node is decoupled from its module loader. The module loader system is just JS that runs on top of the global `process` object which has all the built-in goodies.
Additionally there is no such thing as a global require. That is something unique to our providesModule system. In other module systems such as node, every require is contextual. Even registered npm names are localized by version.
The only global namespace that is accessible to the host environment is the global object. Normally module systems attaches itself onto the hooks provided by the host environment on the global object.
Currently, we have two forms of dispatch that reaches directly into the module system. executeJSCall which reaches directly into require. Everything now calls through the BatchedBridge module (except one RCTLog edge case that I will fix). I propose that the executors calls directly onto `BatchedBridge` through an instance on the global so that everything is guaranteed to go through it. It becomes the main communication hub.
I also propose that we drop the dynamic requires inside of MessageQueue/BatchBridge and instead have the modules register themselves with the bridge.
executeJSCall was originally modeled after the XHP equivalent. The XHP equivalent was designed that way because the act of doing the call was the thing that defined a dependency on the module from the page. However, that is not how React Native works.
The JS side is driving the dependencies by virtue of requiring new modules and frameworks and the existence of dependencies is driven by the JS side, so this design doesn't make as much sense.
The main driver for this is to be able to introduce a new module system like Prepack's module system. However, it also unlocks the possibility to do dead module elimination even in our current module system. It is currently not possible because we don't know which module might be called from native.
Since the module system now becomes decoupled we could publish all our providesModule modules as npm/CommonJS modules using a rewrite script. That's what React Core does.
That way people could use any CommonJS bundler such as Webpack, Closure Compiler, Rollup or some new innovation to create a JS bundle.
This diff expands the executeJSCalls to the BatchedBridge's three individual pieces to make them first class instead of being dynamic. This removes one layer of abstraction. Hopefully we can also remove more of the things that register themselves with the BatchedBridge (various EventEmitters) and instead have everything go through the public protocol. ReactMethod/RCT_EXPORT_METHOD.
public
Reviewed By: vjeux
Differential Revision: D2717535
fb-gh-sync-id: 70114f05483124f5ac5c4570422bb91a60a727f6
Summary:
In order to be able to reliable identify unbundles when loading files, prepend a magic number (0xFB0BD1E5)
public
Reviewed By: martinbigio
Differential Revision: D2734359
fb-gh-sync-id: b469e26459234e7f6270fffa0b872a93d137381d
Summary: fixes https://github.com/facebook/react-native/issues/3997
the root cause is in
Mon, 09 Nov 2015 13:22:47 GMT ReactNativePackager:SocketServer uncaught error Error: listen EACCES C:\Users\donald\AppData\Local\Temp\react-packager-9248a9803ac72b509b389b456696850d
This means that the socket server cannot create the socket.
cfr https://gist.github.com/domenic/2790533 the socket name is not a valid windows socket name.
Closes https://github.com/facebook/react-native/pull/4071
Reviewed By: mkonicek
Differential Revision: D2699546
Pulled By: davidaurelio
fb-gh-sync-id: 6c6494c14c42bb17506b8559001419c9f85e91e3
Summary: This adds a build option for using Prepack (an experimental packager) to
build a bundle. It doesn't actually take on the npm package dependency
because it's not published/open source (yet).
This will be used while we experiment and should be maintained as the
build system changes so that we can continue getting fresh builds.
I found that saveBundleAndMap and processBundle were over abstracted and
got in my way so I inlined it and removed the unit tests because the unit
test was testing trivial code that is likely to change interface.
I went with a separate build phase and a separate Bundle class even though
there are a lot of commonalities. I imagine that the requirements for
Prepack will continue to diverge. Especially for source maps but a larger
refactor could try to unify these a bit more. The fact that modules are
wrapped before the write phase seems to be an unfortunate architecture
that makes this difficult.
Closes https://github.com/facebook/react-native/pull/4226
Reviewed By: amasad
Differential Revision: D2673760
Pulled By: sebmarkbage
fb-gh-sync-id: 299ccc42e4be1d9dee19ade443ea3388db2e39a8
Summary: ```
* What went wrong:
Execution failed for task ':app:bundleReleaseJsAndAssets'.
> A problem occurred starting process 'command 'react-native''
```
Can be solved by this patch.
Closes https://github.com/facebook/react-native/pull/4209
Reviewed By: svcscm
Differential Revision: D2669661
Pulled By: foghina
fb-gh-sync-id: 951b7eb9dd3121de607cf5eb3dfb3af44cdf5994
Summary: The packager was adding compression middleware too late in the stack. This makes things a little faster especially if you're loading through dynamic DNS for example.
Closes https://github.com/facebook/react-native/pull/4121
Reviewed By: svcscm
Differential Revision: D2664373
Pulled By: frantic
fb-gh-sync-id: 46cce81ff6d9e4e71e1718d7e96b58449c248bc1
Summary: public
RFC: The minifier haven't been stripping dead-code, and it also can't kill unused
modules, so as a temporary solution this inlines `__DEV__`, kill dead branches
and kill dead modules. For now I'm just white-listing the dev variable, but we
could definitely do better than that, but as a temporary fix this should be
helpful.
I also intend to kill some dead variables, so we can kill unused requires,
although inline-requires can also fix it.
Reviewed By: vjeux
Differential Revision: D2605454
fb-gh-sync-id: 50acb9dcbded07a43080b93ac826a5ceda695936
Summary: public
The log register function was updated, but the test example wasn't.
Reviewed By: javache
Differential Revision: D2658417
fb-gh-sync-id: 9ad27ec02eb437e0262e71897ff1a58a97e88b6d
Summary: public
The tests are failing, disable it temporarily until it's fixed.
Reviewed By: mkonicek
Differential Revision: D2641730
fb-gh-sync-id: e8e2a8f3e67df197570484d6a8b1d16be08ce1d7
Summary: public
Currently works only on OSX and supports Sublime (2/3) and Atom.
The idea is to get the list of running processes and try to find some well-known
editors there.
Reviewed By: vjeux
Differential Revision: D2642865
fb-gh-sync-id: d346902662354b2f633651a9bc54368146133651
Summary: From http://developer.android.com/guide/topics/resources/runtime-changes.html
> Some device configurations can change during runtime (such as screen orientation, keyboard availability, and language). When such a change occurs, Android restarts the running Activity (onDestroy() is called, followed by onCreate()). The restart behavior is designed to help your application adapt to new configurations by automatically reloading your application with alternative resources that match the new device configuration.
However, in a React Native app, there is only a single activity for the entire app, unlike a single activity per screen in Android, and resources are not specific to orientation etc. Destroying activity means reloading the entire app. Most of the time, this is not the intended behaviour, and can cause data loss for the user if the developer doesn't disable it explicitly. I'm proposing to disable it by default.
Closes https://github.com/facebook/react-native/pull/3813
Reviewed By: svcscm
Differential Revision: D2616083
Pulled By: foghina
fb-gh-sync-id: 8794e436f61581ff0bf569b1b112845cae77b688
Summary: RubyMine's command line launcher `mine` supports the same syntax as `mate` for jumping to line numbers. This patch adds it to the list.
Closes https://github.com/facebook/react-native/pull/3883
Reviewed By: svcscm
Differential Revision: D2615422
Pulled By: pcottle
fb-gh-sync-id: 79a70f524f852ba8eb4803e6abc6970abbf02b61
Summary: This check to see if `require` exists was bad as it throws an error for an
undefined reference in case it doesn't exist.
Closes https://github.com/facebook/react-native/pull/3845
Reviewed By: svcscm
Differential Revision: D2613368
Pulled By: martinbigio
fb-gh-sync-id: 7b1d0f38e4af9bce81356a613d6105f2c00c7ed7
Summary: A lot of people try to use a device as the very first thing when trying
out React Native. I've observed this at the developer workshop in Prague
and on Twitter.
However, developing on pre-API 21 devices is quite involved:
https://facebook.github.io/react-native/docs/running-on-device-android.html
I'm thinking we could recommend installing Android together with Android
studio. Android studio installs HAXM for you (hardware acceleration, without
this Google emulators are useless) and also creates and starts emulators.
So it would be quite a smooth experience similar to pressing 'Run' in Xcode.
We'd just need to integrate with Gradle so that installing the app also starts
the packager. I think that's something we should do in any case.
Probably an even better option is to build a React Native-specific tool that
lets you do everything you need: opens the Android SDK Manager, creates and
starts emulators, detects whether you have Genymotion and opens it, upgrades
node and npm etc.
public
Reviewed By: vjeux
Differential Revision: D2604774
fb-gh-sync-id: c7ffb701b4e5209815faf652926937c22943be95
Summary: Inspired by: https://twitter.com/geirmanc/status/660275638637477889
There are many reasons why the Gradle build could fail and the best
thing to do is to read the error message.
We can provide some hints in the most common cases though.
public
Reviewed By: vjeux
Differential Revision: D2604747
fb-gh-sync-id: 1aa83abb9ec823c03814dcc31d630a8f1914cf5c
Summary: public
We moved to using `new` instead of `alloc] init` but there was still some calls
left.
Reviewed By: javache
Differential Revision: D2604679
fb-gh-sync-id: ff7300ecbedb55dd5e93873592598810c9b87808
Summary: public
Changes were made on the packager that broke the CPU profile upload route,
fix it.
Reviewed By: martinbigio
Differential Revision: D2585184
fb-gh-sync-id: 206744f92d403d6851a69891dfac0c4c11bf1b7e
Summary: Currently on error I have following output:
```
ERROR Packager can't listen on port 8081
Most likely another process is already using this port
Run the following command to find out which process:
lsof -n -i4TCP:8081
You can either shut down the other process:
kill -9 <PID>
or run packager on different port.
See http://facebook.github.io/react-native/docs/troubleshooting.html
for common problems and solutions.
/Users/nucleartux/Work/projects/react-native/local-cli/server/server.js:90
if (error.code === 'EADDRINUSE') {
^
TypeError: Cannot read property 'code' of undefined
at process.<anonymous> (/Users/nucleartux/Work/projects/react-native/local-cli/server/server.js:104:14)
at emitOne (events.js:77:13)
at process.emit (events.js:169:7)
at process._fatalException (node.js:211:26)
```
Closes https://github.com/facebook/react-native/pull/3765
Reviewed By: svcscm
Differential Revision: D2595537
Pulled By: martinbigio
fb-gh-sync-id: e11ec2e6e8794bf5fe7570e27cd327777d8b300c
Summary: public
To improve cold start performance we want to be able to avoid decoding the bundle at all. To make that happen we need to be able to generate a bundle encoded on `ucs2`. This diff adds support for indicating the encoding the Packager should use for bundling.
Reviewed By: davidaurelio
Differential Revision: D2582365
fb-gh-sync-id: 905384272a668910c57a1a2ca6d1b723c39233f8
Summary: public
Aparently this used to work on 0.11, lets fix it :)
Reviewed By: foghina
Differential Revision: D2557719
fb-gh-sync-id: dcbca077431c1356c89dfc55b71eecff64c7ad3d
Summary: public
This is not only to put the files on a place where it makes more sense but also to allow to use ES6 features on them as `/packager` is not whitelisted on `babel`.
Reviewed By: mkonicek
Differential Revision: D2577267
fb-gh-sync-id: b69a17c0aad349a3eda987e33d1778d97a8e1549
Summary: public
This was introduced by vjeux on 0a5967d and removed on 0686b01. I guess it was removed accidentally as this this is a nice warning to have that should prevent n00bs from commiting a common mistake
Reviewed By: frantic
Differential Revision: D2563885
fb-gh-sync-id: 9fae145bbec587514f118d1d28d076b1d82f0630
Summary: public
We cannot remove `local-cli` because is referenced by the global cli explicitly. If we do so, people would have to upgrate this global thin cli which will cause some pain. So, lets move `private-cli` commands into `local-cli` instead.
Reviewed By: frantic
Differential Revision: D2571983
fb-gh-sync-id: 712c29430203660fb6f0d5f23813cb2a7156ee48
Summary: We need to cherry pick this one as well.
cc ide
Closes https://github.com/facebook/react-native/pull/3640
Reviewed By: svcscm
Differential Revision: D2577961
Pulled By: mkonicek
fb-gh-sync-id: 3368fc02a931e0f259f3baa6706bd7d8586b0fbf
Summary: This adds gradle tasks that call `react-native bundle` with the correct args to bundle dev/release JS and assets. The dev task is disabled by default, as in dev mode people only use reload JS in most cases.
Submitting this as a pull request to have community visibility, although we have this code internally as well now and this will require an import.
* generate a project with `react-native init`, add some assets, run `./gradlew assembleRelease`, sign & zipalign generated APK, run it -> works
* enable dev bundling task, run `./gradlew installDebug` (not `react-native run-android` so as to not start the packager) -> works
Reviewed By: svcscm
Differential Revision: D2555071
Pulled By: foghina
fb-gh-sync-id: c3d9fcd4c77862e6a4db4e4d8d8cc39ee9dff3ab
Summary: @public
Lets also make this more generic to allow to generate the template for any platform code.
Reviewed By: @vjeux
Differential Revision: D2536821
fb-gh-sync-id: 6fb99c6dc546b8e1f9839c96a473dc08b0f5285c
Summary: @public
The implementation wasn't working. Lets remove this for now and revisit if we trully want to support this.
Reviewed By: @frantic
Differential Revision: D2536442
fb-gh-sync-id: 4aca2d1d2584cd15ac855d69e6e9a5a08abf778e
Summary: @public
We need to start using the `private-cli` for the new asset system. Note this is a breaking change! People will have to upgrade their workflows/scripts to start using the new cli. Otherwise we'd need to build a thin adapter that is aware of both APIs which is something we;d like to avoid. The major API changes are:
- API is now `entry-file` based instead of `url` based.
- /s/--out/--bundle-output
- /s/--out/--sourcemap-output
Also these parameters have no longer default values, you need to specify them. For instance, if you want to generate the sourcemaps you need to pass in the `--sourcemap-output` option
Lastly, additional project roots or asset roots need to be specified on the `rn-cli.config.js`.
Reviewed By: @frantic
Differential Revision: D2533877
fb-gh-sync-id: a45f9095fdf9442a9106ea7bb6a6b7f651d25273
Summary: @public
We're rolling out a replacement for `local-cli`. As part of the process we moved many hardcoded values into a JS based configuration file.
Reviewed By: @vjeux
Differential Revision: D2533111
fb-gh-sync-id: 7250bddee9989b089ded409104e098ef15d79498
Vsevolod Ivanov
nmccready
Alexandr Pantyuhov
Shayne Sweeney
Martín Bigio
Adam Miskiewicz
Walter Luh
Levy Klots
Geoffrey Goh
djhi
Martin Konicek
David Aurelio
Jagdeep Nagpal
Konstantin Raev
Konstantin Raev
Alex Kotliarskyi
Janic Duplessis
Christopher Chedeau
Nick Lockwood
DengYun
Maksim Ryzhikov
Adam Miskiewicz
Andrew Jack
tdzl2003
Satyajit Sahoo
Patrick Puritscher
Bhuwan Khattar
Philipp von Weitershausen
Sebastian Markbage
Sam Swarr
Christopher Dro
Bram
James Ide
Pasindu Perera
Tadeu Zagallo
Alex Kotliarskyi
Felix Oghina
Kai Wood
Jan Kassens
Chris Geirman
Aaron Chiu
Adrov Igor
Pieter De Baets
Nick Simmons
Ben Vinegar
Atticus White
Felix Oghină
jmhdez
