Summary:
public
Fixes a terrible bug due to which when Hot Loading enabled when the user reloads we'll serve them the first `hot` bundle he requested. This happened because when HMR enabled we bailed out after sending the HMR updates and didn't rebuild any of the bundles the user requested before. As a consequence, when they reload we'd sent him the first and only one we ever built.
The fix is to tweak the hmr listener to return a promise. This way we can run the remaining code on the file change listener just after the HMR stuff finishes. We need to do it this way to avoid the remaining stuff to compete for CPU with the HMR one and give the best possible experience when HMR is enabled.
Reviewed By: davidaurelio
Differential Revision: D2811382
fb-gh-sync-id: 906932d71f35467485cf8a865a8d59f4d2ff41a0
Summary:
public
We're not planning to accept file removals in the short term on the HMR interface so lets bail when a file is removed (before this this we were throwing when trying to get the shallow dependencies).
Reviewed By: yungsters
Differential Revision: D2810534
fb-gh-sync-id: f2733382f4a2619e22bdf1163aa4180694fff9f8
Summary:
public
We want to support Hot Loading on the packager itself instead of on the transformer. This will allow us to enable it on OSS (and for any scripting language, yay!).
For now to enable Hot Loading the packager's internals transforms need to be manually enabled (start packager with `--enable-internal-transforms`). I think the internal pipeline should always be enabled as it doesn't affect performance if there're no transforms and the user can disable Hot Loading through the setting on the app though. I'll tweak this on a follow up commit.
Reviewed By: vjeux
Differential Revision: D2801343
fb-gh-sync-id: 563984d77b10c3925fda6fd5616b814cdbea2c66
Summary:
public
Before this diff we were only accepting the module that was modified but the user. This works fine as long as the user doesn't modify the dependencies a module has but once he starts doing so the HMR runtime may fail when updating modules' code because they might might a few dependencies. For instance, if the user changes the `src` a `Image` has to reference an image (using the new asset system) that wasn't on the original bundle the user will get a red box. This diff addresses this by diffing the modules the app currently has with the new ones it should have and including all of them on the HMR update. Note this diffing is only done when the we realize the module that was modified changed it's dependencies so there's no additional overhead on this change.
Reviewed By: vjeux
Differential Revision: D2796325
fb-gh-sync-id: cac95f2e995310634c221bbbb09d9f3e7bc03e8d
Summary:
public
This diff introduces an internal transforms pipeline that integrates with the external one. This has been a feature we've been looking to implement for a long time to use babel instead of `replace` with regexps on many parts of the packager.
Also, to split the bundle we'll need to run one transform. Internally for Facebook we can run the system-import transform altogether withe the other ones. For OSS we offer `transformer.js` which people can use out of the box if they're writing ES6 code. For those people, `transformer.js` will also run the internal transforms`. However they might want to tune the transforms, or even write the code on another language that compiles to Javascript and use a complete different transformer. On those cases we'll need to run the external transforms first and pipe the output through the internal transforms. Note that the order it's important as the internal transforms assume the code is written in JS, though the original code could be on other scripting languages (CoffeeScript, TypeScript, etc).
Reviewed By: davidaurelio
Differential Revision: D2725109
fb-gh-sync-id: d764e209c78743419c4cb97068495c771372ab90
Summary:
public
Before this this when a file was changed besides sending the HMR update we rebuild every single bundle that the packager had build (to serve it faster when the user hit cmd+r). Since when hot loading is enabled we don't do cmd+r all this work was pointless (except for when you're developing multiple apps using the same packager instance at the same time, which we can assume is very uncommon). As a consequence, the HMR update was competing with the rebundling job making HMR quite slow (i.e.: on one huge internal app it took up to 6s for the HMR changes to get applied).
So, this diff tweaks the file change listener so that we don't rebundle nor invoke the fileWatchers (use for live reload which is also useless when hot load is enabled) when hot loading is enabled. Also, it makes the HMR listener more high pri than the other listeners so that the HMR dev experience is as good as it can get.
Reviewed By: vjeux
Differential Revision: D2793827
fb-gh-sync-id: 724930db9f44974c15ad3f562910b0885e44efde
Summary:
public
Compute the dependencies of the bundle entry file just before sending HMR updates. In case the file that was changed doesn't belong to the bundle bail.
Reviewed By: vjeux
Differential Revision: D2793736
fb-gh-sync-id: f858e71b0dd5fe4f5b2307a22c6cef627eb66a22
Summary:
public
Until we support this fature on OSS, don't show the menu option.
Reviewed By: vjeux
Differential Revision: D2791198
fb-gh-sync-id: 11b66d467c1ab784bbf549b893d0a3abd69e2741
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
Summary:
public
This diff adds infra to both the Packager and the running app to have a WebSocket based connection between them. This connection is toggled by a new dev menu item, namely `Enable/Disable Hot Loading`.
Reviewed By: vjeux
Differential Revision: D2787621
fb-gh-sync-id: d1dee769348e4830c28782e7b650d025f2b3a786
Summary:
Passing around a `getTransformOptions` function doesn't really work with the CLI utils, so I'm changing this to `getTransformOptionsModulePath` instead, which can easily be injected in through `rn-cli.config.js`.
public
Reviewed By: martinbigio
Differential Revision: D2785789
fb-gh-sync-id: c9fdc358cb5d0db27e0d02496e44c013c77f3d5f
Summary:
Currently, the app server accepts `transformModulePath` which allows us to use different transformation variants. However, these options persist through the lifetime of the server. So we cannot conditionally transform a module differently for two bundles without restarting the server with different options.
`getTransformOptions` basically allows us to change the options to the transformer at runtime based on the bundle and module being transformed.
These options are also used as a cache key for the transformedSource to ensure that if a file is transformed with different options, caching doesn't cause any inconsistencies.
public
Reviewed By: martinbigio
Differential Revision: D2776399
fb-gh-sync-id: 1e0f34d8fa7f0377fcf81f23eb6f3236bd397d56
Summary: This adds a build option for using Prepack (an experimental packager) to
build a bundle. It doesn't actually take on the npm package dependency
because it's not published/open source (yet).
This will be used while we experiment and should be maintained as the
build system changes so that we can continue getting fresh builds.
I found that saveBundleAndMap and processBundle were over abstracted and
got in my way so I inlined it and removed the unit tests because the unit
test was testing trivial code that is likely to change interface.
I went with a separate build phase and a separate Bundle class even though
there are a lot of commonalities. I imagine that the requirements for
Prepack will continue to diverge. Especially for source maps but a larger
refactor could try to unify these a bit more. The fact that modules are
wrapped before the write phase seems to be an unfortunate architecture
that makes this difficult.
Closes https://github.com/facebook/react-native/pull/4226
Reviewed By: amasad
Differential Revision: D2673760
Pulled By: sebmarkbage
fb-gh-sync-id: 299ccc42e4be1d9dee19ade443ea3388db2e39a8
Summary: public
RFC: The minifier haven't been stripping dead-code, and it also can't kill unused
modules, so as a temporary solution this inlines `__DEV__`, kill dead branches
and kill dead modules. For now I'm just white-listing the dev variable, but we
could definitely do better than that, but as a temporary fix this should be
helpful.
I also intend to kill some dead variables, so we can kill unused requires,
although inline-requires can also fix it.
Reviewed By: vjeux
Differential Revision: D2605454
fb-gh-sync-id: 50acb9dcbded07a43080b93ac826a5ceda695936
Summary: public
Aparently this used to work on 0.11, lets fix it :)
Reviewed By: foghina
Differential Revision: D2557719
fb-gh-sync-id: dcbca077431c1356c89dfc55b71eecff64c7ad3d
Summary: @public
We've been forgiving unresolved modules errors in the past but we've realized that doing so makes the codebase a bit unstable as people don't make sure to fix these errors. From now on we'll early fail and stop the packager when any module cannot be resolved (including assets)
Reviewed By: @amasad
Differential Revision: D2518076
fb-gh-sync-id: e170d95b905cc29afbe46e24b65425ddd887f77c
Summary: @public
The source maps generated by uglify are already stringified, and therefore were
being stringified twice.
Reviewed By: @martinbigio
Differential Revision: D2498242
Summary: @public
Since we added packager-managed assets -- internally we still think of asset dependency as a single "module". In reality there are multiple files that represent this module. This becomes important with the `getDependencies` API which is used by Buck to inform it on what to rebuild. Since `getDependencies` deals with modules, and is more of an internal API, I've introduced a new one and would go on to deprecate this.
Reviewed By: @frantic
Differential Revision: D2487207
Summary: @public
Invoking an extra promise caused failures in the promise-based tests. This fixes them.
Reviewed By: @vjeux
Differential Revision: D2432431
Summary: how did this ever work?
All build jobs must pass in the platform argument.
This also turns the "platform" argument into a required one.
I added a task to infer the platform argument from the filename here: t8306875
Reviewed By: @martinbigio
Differential Revision: D2425114
Summary: @public
The profiler helper shouldn't live inside the packager itself, move
it to the packager.js file with other middlewares.
Reviewed By: @martinbigio
Differential Revision: D2424878
Summary:
We don't currently support platform extensions in asset modules.
This adds supports for it:
```
require('./a.png');
```
Will require 'a.ios.png' if it exists and 'a.png' if it doesn't.
Summary:
Sourcemap urls were generated as just the pathname (no options) which meant that they generated source for the wrong bundle.
Even worse, there exists a race condition when multiple request to the same bundle has different types of paltform arguments (in this case one could be 'ios' and the other is undefined). The fix will this will come later as it's more involved -- will need to refactor the dependency resolver to have a per-request state.
Summary:
There's been a case where Babel can hang indefinitely on a file parse/transform. Possibly related to https://github.com/babel/babel/issues/2211
This adds a timeout to transform jobs and throws an error informing the user of the offending file. The timeout interval defaults to 10 seconds, but can be changed via an option.
Summary:
Currently the platform selection is controlled by the blacklist. However, since we want to use the same server instance for cross-platform development, we need this to be controlled per request.
One outstanding issue, is that the DependencyGraph class wasn't designed that way and it doesn't have a per-request state. This means that with the current design race conditions is possible. If we got a request for a different platfrom while processing the previous request, we may change the outcome of the previous request.
To fix this a larger refactor is needed. I'll follow up a diff to do that.
Finally, so I don't break the universe like last time, I'll leave it up to the RN guys to update the call sites.
Summary:
The word Package is overloaded, it may mean npm package, or may mean a collection of bundles. Neither is what we mean. We mean `bundle`.
This renames it and modernize some of the Bundler code.
