react-native/packager
Martín Bigio 4ffb241647 Hot Loading E2E basic flow
Summary:
public

Implement all the necessary glue code for several diffs submitted before to get Hot Loading work end to end:

- Simplify `HMRClient`: we don't need to make it stateful allowing to enable and disable it because both when we enable and disable the interface we need to reload the bundle.
- On the native side we introduced a singleton to process the bundle URL. This new class might alter the url to include the `hot` attribute. I'm not 100% sure this is the best way to implement this but we cannot use `CTLSettings` for this as it's are not available on oss and I didn't want to contaminate `RCTBridge` with something specific to hot loading. Also, we could potentially use this processor for other things in the future. Please let me know if you don't like this approach or you have a better idea :).
- Use this processor to alter the default bundle URL and request a `hot` bundle when hot loading is enabled. Also make sure to enable the HMR interface when the client activates it on the dev menu.
- Add packager `hot` option.
- Include gaeron's `react-transform` on Facebook's JS transformer.

The current implementation couples a bit React Native to this feature because `react-transform-hmr` is required on `InitializeJavaScriptAppEngine`. Ideally, the packager should accept an additional list of requires and include them on the bundle among all their dependencies. Note this is not the same as the option `runBeforeMainModule` as that one only adds a require to the provided module but doesn't include all the dependencies that module amy have that the entry point doesn't. I'll address this in a follow up task to enable asap hot loading (9536142)

I had to remove 2 `.babelrc` files from `react-proxy` and `react-deep-force-update`. There's an internal task for fixing the underlaying issue to avoid doing this horrible hack (t9515889).

Reviewed By: vjeux

Differential Revision: D2790806

fb-gh-sync-id: d4b78a2acfa071d6b3accc2e6716ef5611ad4fda
2015-12-28 16:44:59 -08:00
..
react-packager Hot Loading E2E basic flow 2015-12-28 16:44:59 -08:00
README.md getTransformOptionsModulePath 2015-12-24 01:02:30 -08:00
babelRegisterOnly.js Upgrade transformers to be compatible babel 6 2015-11-10 10:55:23 -08:00
blacklist.js RN: Install Updated `fbjs` Downstream 2015-12-16 01:49:15 -08:00
launchPackager.command Fix launchCommand 2015-11-11 04:39:28 -08:00
package.json Fix cli entry points 2015-10-22 10:13:13 -07:00
packager.sh Fix cli entry points 2015-10-22 10:13:13 -07:00
react-native-xcode.sh Add support for nodenv with xcode 2015-12-17 14:10:36 -08:00
rn-cli.config.js Allow user to configure transformer through cl argument 2015-10-16 13:26:22 -07:00
transformer.js Support plugins that conform to ES6 modules 2015-12-04 07:45:29 -08:00

README.md

React Native Packager

React Native Packager is a project similar in scope to browserify or 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 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 proprietary module format known as @providesModule. However, we discourage people to use this module format because going forward, we want to completely separate our infrastructure from React Native and provide an experience most JavaScript developers are familiar with, 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 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!).

HTTP interface

The main way you'd interact with the packager is via the HTTP interface. The following is the list of endpoints and their respective functions.

/path/to/moduleName.bundle

Does the following in order:

  • parse out path/to/moduleName
  • add a .js suffix to the path
  • looks in your project root(s) for the file
  • recursively collects all the dependencies from an in memory graph
  • runs the modules through the transformer (might just be cached)
  • concatenate the modules' content into a bundle
  • responds to the client with the bundle (and a SourceMap URL)

/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
  • 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.

Note that source map generation currently assumes that the code has been compiled with jstransform, which preserves line and column numbers which allows us to generate source maps super fast.

/path/to/moduleName.(map|bundle) query params

You can pass options for the bundle creation through the query params, if the option is boolean 1/0 or true/false is accepted.

Here are the current options the packager accepts:

  • dev boolean, defaults to true: sets a global __DEV__ variable which will effect how the React Native core libraries behave.
  • 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') 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:

  • 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

Programmatic API

The packager is made of two things:

  • The core packager (which we're calling ReactPackager)
  • The scripts, devtools launcher, server run etc.

ReactPackager is how you mainly interact with the API.

var ReactPackager = require('./react-packager');

ReactPackager.middleware(options)

Returns a function that can be used in a connect-like middleware. Takes the following options:

  • projectRoots array (required): Is the roots where your JavaScript file will exist
  • blacklistRE regexp: Is a patter to ignore certain paths from the 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 disk
  • transformModulePath string: Path to the module used as a JavaScript transformer
  • nonPersistent boolean, defaults to false: Whether the server should be used as a persistent deamon to watch files and update itself
  • assetRoots array: Where should the packager look for assets
  • getTransformOptionsModulePath string: Path to module that exports a function that acts as a middleware for generating options to pass to the transformer based on the bundle and module being transformed.

ReactPackager.buildPackageFromUrl(options, url)

Build a package from a url (see the .bundle endpoint). options is the same options that is passed to ReactPackager.middleware

ReactPackager.getDependencies(options, main)

Given an entry point module. Recursively collect all the dependent modules and return it as an array. options is the same options that is passed to ReactPackager.middleware

Debugging

To get verbose output when running the packager, define an environment variable:

export DEBUG=ReactNativePackager:*

You can combine this with other values, e.g. DEBUG=babel,ReactNativePackager:*. Under the hood this uses the debug package, see its documentation for all the available options.

The /debug endpoint discussed above is also useful.

FAQ

Can I use this in my own non-React Native project?

Yes. It's not really tied to React Native, however feature development is informed by React Native needs.

Why didn't you use webpack?

We love webpack, however, when we tried on our codebase it was slower than our developers would like it to be. You can find more discussion about the subject here.