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
Summary: beeper node modules has a `return` statement outside of a function which doesn't parse. To fix it, we mock it. Also, setupEnvPolyfills is no longer being used.
Closes https://github.com/facebook/react-native/pull/2770
Reviewed By: @svcscm
Differential Revision: D2448882
Pulled By: @vjeux
This is an early release and there are several things that are known
not to work if you're porting your iOS app to Android.
See the Known Issues guide on the website.
We will work with the community to reach platform parity with iOS.
Added bundle script
Pipe http response straight to file
Used ReactPackager directly, minor fixes
Added error handling to fs.writeFile
Changed .then to .done