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
David Aurelio
Sebastian Markbage
Sam Swarr
Christopher Dro
Bram
DengYun
James Ide
Pasindu Perera
Tadeu Zagallo
Martin Konicek
Alex Kotliarskyi
Felix Oghina
Satyajit Sahoo
Kai Wood
Martín Bigio
Jan Kassens
Chris Geirman
Aaron Chiu
Adrov Igor
Alex Kotliarskyi
