Updates from Wed 1 Apr
- Packager status page & build validating against it. | Spencer Ahrens - Do not expose define references in require polyfill | Amjad Masad
This commit is contained in:
parent
89f52893cd
commit
da6766d644
|
@ -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 */
|
||||
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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) {
|
||||
|
|
|
@ -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;
|
||||
|
|
Loading…
Reference in New Issue