Merge pull request #581 from vjeux/update1

Updates from Wed 1 Apr

React/React.xcodeproj/project.pbxproj

@@ -445,7 +445,7 @@
 			);
 			runOnlyForDeploymentPostprocessing = 0;
 			shellPath = /bin/sh;
-			shellScript = "nc -w 5 -z localhost 8081 > /dev/null 2>&1 || open $SRCROOT/../packager/launchPackager.command || echo \"Can't start packager automatically\"";
+			shellScript = "if nc -w 5 -z localhost 8081 ; then\n  if ! curl -s \"http://localhost:8081/status\" | grep -q \"packager-status:running\" ; then\n    echo \"Port 8081 already in use, packager is either not running or not running correctly\"\n    exit 2\n  fi\nelse\n  open $SRCROOT/../packager/launchPackager.command || echo \"Can't start packager automatically\"\nfi";
 		};
 /* End PBXShellScriptBuildPhase section */
 

packager/README.md

@@ -2,12 +2,12 @@ React Native Packager
 --------------------
 
 React Native Packager is a project similar in scope to browserify or
-webpack; it provides a CommonJS-like module system, JavaScript
+webpack, it provides a CommonJS-like module system, JavaScript
 compilation (ES6, Flow, JSX), bundling, and asset loading.
 
 The main difference is the Packager's focus on compilation and
 bundling speed. We aim for a sub-second edit-reload
-cycle. Additionally, we don't want users -- with large code bases --
+cycles. Additionally, we don't want users -- with large code bases --
 to wait more than a few seconds after starting the packager.
 
 The main deviation from the node module system is the support for our
@@ -19,7 +19,7 @@ namely the node module format. We want to even go further, and let you
 choose your own packager and asset pipeline or even integrate into
 your existing infrastructure.
 
-React Native users need not to understand how the packager works;
+React Native users need not to understand how the packager work,
 however, this documentation might be useful for advanced users and
 people who want to fix bugs or add features to the packager (patches
 welcome!).
@@ -45,10 +45,10 @@ Does the following in order:
 ### /path/to/moduleName.map
 
 * if the package has been previously generated via the `.bundle`
-  endpoint, then the source map will be generated from that package
+  endpoint then the source map will be generated from that package
 * if the package has not been previously asked for, this will go
-  through the same steps outlined in the `.bundle` endpoint, then
-  generate the source map
+  through the same steps outlined in the `.bundle` endpoint then
+  generate the source map.
 
 Note that source map generation currently assumes that the code has
 been compiled with jstransform, which preserves line and column
@@ -66,15 +66,15 @@ Here are the current options the packager accepts:
 * `minify` boolean, defaults to false: whether to minify the bundle.
 * `runModule` boolean, defaults to true: whether to require your entry
   point module. So if you requested `moduleName`, this option will add
-  a `require('moduleName')` to the end of your bundle.
+  a `require('moduleName')` the end of your bundle.
 * `inlineSourceMap` boolean, defaults to false: whether to inline
   source maps.
 
 ### /debug
 
-This is a page used for debugging; it has links to two pages:
+This is a page used for debugging, it has links to two pages:
 
-* Cached Packages: which shows you the packages that have already been
+* Cached Packages: which shows you the packages that's been already
   generated and cached
 * Dependency Graph: is the in-memory graph of all the modules and
   their dependencies
@@ -103,8 +103,8 @@ middleware. Takes the following options:
   packager
 * `polyfillModuleName` array: Paths to polyfills you want to be
   included at the start of the bundle
-* `cacheVersion` string: Used in creating the cache file
-* `resetCache` boolean, defaults to false: Whether to use the cache on
+* `cacheVersion` string: used in creating the cache file
+* `resetCache` boolean, defaults to false: whether to use the cache on
   disk
 * `transformModulePath` string: Path to the module used as a
   JavaScript transformer
@@ -133,6 +133,6 @@ is informed by React Native needs.
 
 ### Why didn't you use webpack?
 
-We love webpack; however, when we tried it on our codebase, it was slower
-than our developers wanted it to be. You find can more discussion about
-the subject [here](https://github.com/facebook/react-native/issues/5).
+We love webpack, however, when we tried on our codebase it was slower
+than our developers would like it to be. You find can more discussion about
+the subject [here](https://github.com/facebook/react-native/issues/5)

packager/packager.js

@@ -150,6 +150,17 @@ function getDevToolsLauncher(options) {
   };
 }
 
+// A status page so the React/project.pbxproj build script
+// can verify that packager is running on 8081 and not 
+// another program / service.
+function statusPageMiddleware(req, res, next) {
+  if (req.url === '/status') {
+    res.end('packager-status:running');
+  } else {
+    next();   
+  }
+}
+
 function getAppMiddleware(options) {
   return ReactPackager.middleware({
     projectRoots: options.projectRoots,
@@ -168,6 +179,7 @@ function runServer(
     .use(loadRawBody)
     .use(openStackFrameInEditor)
     .use(getDevToolsLauncher(options))
+    .use(statusPageMiddleware)
     .use(getAppMiddleware(options));
 
   options.projectRoots.forEach(function(root) {

packager/react-packager/src/DependencyResolver/haste/polyfills/require.js

@@ -586,15 +586,11 @@
   _register('module', 0);
   _register('exports', 0);
 
-  _register('define', define);
   _register('global', global);
   _register('require', require);
   _register('requireDynamic', require);
   _register('requireLazy', requireLazy);
 
-  define.amd = {};
-
-  global.define = define;
   global.require = require;
   global.requireDynamic = require;
   global.requireLazy = requireLazy;