Summary:
Buck (our build system) currently starts multiple packager instances for each target and may build multiple targets in parallel. This means we're paying startup costs and are duplicating the work. This enables us to start one instance of the packager and connect to it via socket to do all the work that needs to be done.
The way this is structured:
1. SocketServer: A server that listens on a socket path that is generated based on the server options
2. SocketClient: Interfaces with the server and exposes the operations that we support as methods
3. SocketInterface: Integration point and responsible for forking off the server
Summary:
TabBarItemIOS supports setting the scale for base64-encoded images using an optional scale parameter, however this was broken due to the JS code only passing the uri, not the whole source object, to the native side.
(See: https://github.com/facebook/react-native/issues/2413)
Summary:
This suppresses this output from npm:
```
npm ERR! Failed at the react-native@0.9.0 start script './packager/packager.sh'.
npm ERR! This is most likely a problem with the react-native package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! ./packager/packager.sh
npm ERR! You can get their info via:
npm ERR! npm owner ls react-native
```
We don't seem to have any automated scripts that rely on the exit code of npm start (or even call it at all).
Closes https://github.com/facebook/react-native/pull/2415
Github Author: Ben Alpert <balpert@fb.com>
Summary:
The transform step in currently the longest one in the bundling process. This adds a progress bar to track the transform progress.
{F23096660}
Summary:
The path to the iOS 8.3 SDK does not exist when only Xcode 6.4 is installed. This uses a more general folder name, which (at least) the 8.4 SDK symlinks to.
I haven't verified this on Xcode 6.3, so I'd appreciate it if someone could confirm that this path exists there too! :)
Summary:
There are two fs steps and it wasn't clear why. This now puts the right label:
```
[9:38:25 PM] <START> Building in-memory fs for JavaScript
[9:38:27 PM] <END> Building in-memory fs for JavaScript (2030ms)
[9:38:27 PM] <START> Building in-memory fs for Assets
[9:38:27 PM] <END> Building in-memory fs for Assets (615ms)
```
There was a problem where NVM_DIR wasn't correctly configured, which meant that `npm install` was using whatever version of Node was on the system (0.12 in this case) despite having run `nvm use iojs-v2`. Fixing up NVM_DIR fixes the `npm install` errors and builds the native npm packages for the right version of Node.
Summary:
The `BundlesLayout` will be used as a persistent index. As such, it would be easier to avoid having dependencies to `Module`, `Package`, `Asset`, etc. We're not using that information for now and if we happen to need to use it we could always fetch it using the `ModuleCache`.
Summary:
We've decided to move the syntax for asynchronously requiring async dependencies. The new syntax works better with promises and therefore withe async/await as well. The new syntax looks like this: `System.import('moduleA').then(moduleA => {...});` or if you're using async/await you could simply do:
let moduleA = await System.import('moduleA');
new moduleA().someFunction();
If you need to require multiple dependencies just do:
Promise
.all([System.import('moduleA'), System.import('moduleB')])
.then((moduleA, moduleB) => {...})
or the equivalent using async/await
Andrei Coman
Amjad Masad
Andy Street
Martin Konicek
Martin Konicek
chirag04
Natansh Verma
Alexey Lang
Matt Mahoney
Krzysztof Magiera
Nick Lockwood
Pieter De Baets
Alex Akers
Tadeu Zagallo
Jing Chen
Ben Alpert
Martín Bigio
Justin Spahr-Summers
Tim Yung
Christopher Chedeau
Christopher Chedeau
James Ide
Alex Kotliarskyi