Summary:
One consequence we didn't predict after introducing the Internal Transform Pipeline, was that when the workers would get started, we won't require the external transformer the user specified up until the first time each worker received a job. There're 2 visible consequences of this: (1) the transform progress bar seems to get stuck for about 5 seconds the first time the packager receives a request and (2) the first N (# of cores) HMR requests take way longer (about 4 seconds with FB's transformer instead of << 1 second) as we need to require lots of modules.
This diff creates a temporary file for the js transformer workers that requires the user-specified transform file eagerly.
That makes sure workers have imported babel and the transforms before receiving the first request.
There are better ways to do this, like adding an `init()` method to the workers and call that eagerly. I will follow with another diff doing that.
public
Reviewed By: javache
Differential Revision: D2812153
fb-gh-sync-id: 15be316b792d1acd878ed9303bea398aa0b52e1d
Summary:
I'm working on deploying haste2 with jest. This updates all the files that require changes for this to work and they are backwards compatible with the current version of jest.
* package.json was just outdated. I think haste1's liberal handling with collisions made this a "non-issue"
* env.js didn't properly set up ErrorUtils, also unsure why that isn't a problem in jest right now already?
* some things were mocking things they shouldn't
* Because of the regex that matches against providesModule and System.import, it isn't possible to list module names more than once. We have multiple tests reusing the same providesModule ids and using System.import with modules that only exist virtually within that test. Splitting up the strings makes the regexes work (we do the same kind of splitting on www sometimes if we need to) and using different providesModule names in different test files fixes the problem. I think the BundlesLayoutIntegration-test is going to be deleted, so this doesn't even matter.
public
Reviewed By: voideanvalue
Differential Revision: D2809681
fb-gh-sync-id: 8fe6ed8b5a1be28ba141e9001de143e502693281
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:
This fixes an error introduced in `0.18.0-rc`
`node` and `npm` isn't available if the developer is using `nvm` or `nodeenv`. XCode throws an error because of the call to `npm`. Simple move the line to after `node` and `npm` has been setup.
Closes https://github.com/facebook/react-native/pull/5156
Reviewed By: svcscm
Differential Revision: D2807589
Pulled By: androidtrunkagent
fb-gh-sync-id: 30c33145b2cb6f30ff67f6648153d5aa67fb74ed
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
Requires are transformed when building the bundle but we forgot doing so when building the HMR one.
Reviewed By: vjeux
Differential Revision: D2801319
fb-gh-sync-id: ae70612945ab81a05154b14d6b756ef390770542
Summary:
public
Fixes an issue on the transforms pipeline which caused not to pipe errors that occured on the external transformer to JSTransformer.
Reviewed By: yungsters
Differential Revision: D2806498
fb-gh-sync-id: c9347d1957a3a9320b3f177ff9b19bf3802087a0
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:
We don't (yet) treat these the same as any other modules because we still have special resolution rules for them in the packager allowing the use of `providesModule`, but I believe this allows people to use npm react in their RN projects and not have duplicate copies of React. Fixesfacebook/react-native#2985.
This relies on fbjs 0.6, which includes `.flow` files alongside the `.js` files to allow them to be typechecked without additional configuration. This also uses react 0.14.5, which shims a couple of files (as `.native.js`) to avoid DOM-specific bits. Once we fix these in React, we will use the same code on web and native. Hopefully we can also remove the packager support I'm adding here for `.native.js`.
This diff is not the desired end state for us – ideally the packager would know nothing of react or fbjs, and we'll get there eventually by not relying on `providesModule` in order to load react and fbjs modules. (fbjs change posted here but not merged yet: https://github.com/facebook/fbjs/pull/84.)
This should also allow relay to work seamlessly with RN, but I haven't verified this.
public
Reviewed By: sebmarkbage
Differential Revision: D2786197
fb-gh-sync-id: ff50f28445e949edc9501f4b599df7970813870d
Summary:
These are the sources, not the target. Copy pasta from above.
Closes https://github.com/facebook/react-native/pull/4989
Reviewed By: svcscm
Differential Revision: D2795198
Pulled By: spicyj
fb-gh-sync-id: 61c52add02cb877284fbf62a4344361b5bf44515
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
Add a very simple runtime for self-accepting modules. The API is the same one as Webpacks's one for now.
The new infra will be end-to-end tested on a follow up diff.
Reviewed By: vjeux
Differential Revision: D2789428
fb-gh-sync-id: c39524814d53c6e4ec9d9d011081ea81089b00b6
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:
public
The Whole Program Optimisation (WPO) pass is quite slow, and can make it painful
to iterate when having `dev=false`. Move it to happen only when both `dev=false` and `minify=true`.
Reviewed By: davidaurelio
Differential Revision: D2773941
fb-gh-sync-id: ac5ca4e1286e233c2d175eecdbf7494d5d3497b2
Summary:
There's quite a bit of code scattered around the packager regarding ignoring the `providesModule` Haste pragma in any file that isn't in `react-native`, `react-tools` or `parse`. There is even a (passing) test case.
However, there's an edge case.
Take, for example, `fbjs`. It has a module inside of it called `ErrorUtils`. `react-relay` requires this file normally, in Common.JS style, by doing `require('fbjs/libs/ErrorUtils')`. But when `react-native` attempts to require `ErrorUtils` using the HasteModule format (in it's JavaScript initialization), it resolves the `fbjs` `ErrorUtils` module, instead of RN's `ErrorUtils`.
This happens, it turns out, because when a module is read (in `Module._read`), it's not caring about whether or not it should pay attention to `providesModule`, and is just assigning the `providesModule` value as the id of the module no matter what. Then when `Module.getName` is called, it will always use that `data.id` that was set, thus creating the wrong dependency tree.
This
Closes https://github.com/facebook/react-native/pull/3625
Reviewed By: svcscm
Differential Revision: D2632317
Pulled By: vjeux
fb-gh-sync-id: efd8066eaf6f18fcf79698beab36cab90bf5cd6d
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:
Here are some small fixes for issues we've encountered with very large RN projects (mostly huge dependency trees in `node_modules`).
cc amasad martinbigio
Closes https://github.com/facebook/react-native/pull/4880
Reviewed By: svcscm
Differential Revision: D2782834
Pulled By: mkonicek
fb-gh-sync-id: e316a62b84ba796b80ac819431414ebf27f7b566
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:
public
The minified bundle was always being generated with the `bundle.js` as the source map url.
Reviewed By: martinbigio
Differential Revision: D2773725
fb-gh-sync-id: 02cda95eb172fc373ce4e605418cbfcec22f433d
Summary:
Hello!
I'm a fan of the *env family of version managers over the *vm family as I find them simpler and less obtrusive, but it seems that they don't currently work so well with react-native on OSX. See #4645
I've made a small addition to the xcode script that resolves the issue for me. Hopefully others will find this useful too :)
If I've not made the right move here, what is the correct way to get react-native projects building in xcode when the binary is not in the $PATH used by the script?
Cheers,
Louis
Closes https://github.com/facebook/react-native/pull/4801
Reviewed By: svcscm
Differential Revision: D2770726
Pulled By: androidtrunkagent
fb-gh-sync-id: 3b0f9e466549b3012a68c94738d2556173f4c21e
Summary:
If a console exists, keep the original as `global.originalConsole` before overwriting `global.console` with a polyfill. This matches what we do for XHR, fetch, and some other libraries.
Closes https://github.com/facebook/react-native/pull/3322
Reviewed By: svcscm
Differential Revision: D2755873
Pulled By: androidtrunkagent
fb-gh-sync-id: 4c23f807b73b79cfa9fbbd4e2814d76eecabd596
Summary:
in ```fastfs.js ``` when ```getFile()``` got a exception it will print ``` Unable to find file with path: null ``` in terminal .
It's confused
Closes https://github.com/facebook/react-native/pull/4737
Reviewed By: svcscm
Differential Revision: D2752888
Pulled By: androidtrunkagent
fb-gh-sync-id: a366da1eea27c691248dcb17019f4462a639ea70
Summary:
Related to issue https://github.com/facebook/react-native/issues/4034#issuecomment-164134543.
The npm global install path may be set to a non-standard location. `react-native` is assumed to be in `PATH` but doesn't take into account the user's environment so building in Xcode fails:
~~~
react-native bundle --entry-file index.ios.js --platform ios --dev true --bundle-output [...]
../node_modules/react-native/packager/react-native-xcode.sh: line 48: react-native: command not found
Command /bin/sh failed with exit code 127
~~~
This fix uses `npm prefix -g` to get the bin location and adds it to `PATH`.
Closes https://github.com/facebook/react-native/pull/4749
Reviewed By: svcscm
Differential Revision: D2753215
Pulled By: androidtrunkagent
fb-gh-sync-id: 964d1a71ac1bf204545a594a9fa433a7bc367f35
Martin Bigio
Christoph Pojer
David Aurelio
Henrik Kok Jørgensen
Janic Duplessis
Ben Alpert
wvengen
Ben Alpert
Tadeu Zagallo
Adam Miskiewicz
Bhuwan Khattar
Philipp von Weitershausen
Louis Pilfold
Martin Konicek
Tim Yung
Baris Sencan
James Ide
WanderWang
Billy Lamberta