Summary:
This will throw an error message with the problematic callback module/method. Previously we would get an invariant in this case when we try to access `callback.apply` later in the method.
Summary:
A few potential races to fix:
1. Multiple clients maybe racing to delete a zombie socket
2. Servers who should die because other servers are already listening are taking the socket with them (move `process.on('exit'` code to after the server is listening
3. Servers which are redundant should immediatly die
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)
```
