Summary:
public
Since the combination of node and haste modules (and modules that can be required as both node and haste module) can lead to situations where it’s impossible to decide an unambiguous module identifier, this diff switches all module ids to integers. Each integer maps to an absolute path to a JS file on disk.
We also had a problem, where haste modules outside and inside node_modules could end up with the same module identifier.
This problem has not manifested yet, because the last definition of a module wins. It becomes a problem when writing file-based unbundle modules to disk: the same file might be written to concurrently, leading to invalid code.
Using indexed modules will also help indexed file unbundles, as we can encode module IDs as integers rather than scanning string IDs.
Reviewed By: martinbigio
Differential Revision: D2842418
fb-gh-sync-id: 97addd28e964ac5f2b5081dcd3f36124d2864df8
Summary:
public
We had a bug a few weeks ago which caused transform errors not to be shown properly. The problem was on this piece of code, so lets unit test it.
Reviewed By: davidaurelio
Differential Revision: D2849990
fb-gh-sync-id: 9f6bb8a8b7d59bbaa3577c29cee37fb23a50d66f
Summary:
There's a long standing issue on open source (https://github.com/facebook/react-native/issues/4968). Until someone gets some free bandwidth to fix it lets at the very least improve the error message to guide users to the issue and suggest workarounds.
public
Reviewed By: mkonicek
Differential Revision: D2849051
fb-gh-sync-id: ef7913442ceabcab2076141bd13ab1ceeb529759
Summary:
At the moment we have to disable strict mode for the transform-es2015-modules-commonjs because strict mode leaks to the global scope and breaks the bridge. It was due to the way the polyfills were bundled in the package. To fix it, I wrapped the polyfill modules in an IIFE. Then when strict mode was enabled some polyfills were broken due to strict mode errors so that was fixed too. Also removed the IIFE from the polyfills that included one.
This diff doesn't enable the strict mode transform since some internal facebook modules depend on it not being enabled. When #5214 lands we could make the default babel config shipped with OSS react-native use strict mode modules and facebook could just modify the babel config to disable it if needed.
This will allow removing `"strict": false` from https://github.com/facebook/react-native/blob/master/packager/react-packager/.babelrc#L16Fixes#5316
Closes https://github.com/facebook/react-native/pull/5422
Reviewed By: svcscm
Differential Revision: D2846422
Pulled By: davidaurelio
fb-gh-sync-id: a3e2f8909aa87dabab2b872c61b887e80220fb56
Summary:
This implements #5073. It adds a static method `PixelRatio.pixel()` which returns the smallest drawable line width, primarily for use in styles.
It also updates the example apps to use the new function.
Closes https://github.com/facebook/react-native/pull/5076
Reviewed By: svcscm
Differential Revision: D2799849
Pulled By: nicklockwood
fb-gh-sync-id: b83a77790601fe882affbf65531114e7c5cf4bdf
Summary:
public
- Tweak OSS server to enable the HMR connection
- Remove client gating code.
- Resolve internal transforms plugins
After this diff, Hot Loading should work on OSS.
Reviewed By: javache
Differential Revision: D2803620
fb-gh-sync-id: b678180c884d2bfaf454edf9e7abe6b3b3b32ebe
Summary:
We used to only cache the `dependencies` and `name` of a Module but we were actually accessing two more fields (async dependencies and the `isHaste` field) which meant we were always reading every single file from disk. In D2644383 I noticed that but realized that the Promise was cached, meaning we would read every file once *per instance* and I didn't think about cross-instance reads over time. My initial version added more caching (but also missed the `isHaste` field) but then I got rid of the cache call for `dependencies`. So my change from before didn't make anything worse but it also didn't make anything better. This change now caches everything until the contents of the file actually changes.
public
Reviewed By: martinbigio
Differential Revision: D2831569
fb-gh-sync-id: 74081abc0ce3ca96b4e56c3c9b6d24aa84f7496c
Summary:
It's possible that a mock doesn't have an associated real module that it maps to. This is actually very common in www, where we have JS mocks for dynamic PHP JS modules. The implementation I chose seems like the smartest one for now: if a module cannot be resolved, we look up whether we have a mock with the same id. If we do, we just resolve it. That's it! And it also only does the minimum amount of resolution necessary.
public
Reviewed By: martinbigio
Differential Revision: D2822277
fb-gh-sync-id: 7c9fbb6f69a0c0c85157c0650f5719d94a02410e
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
Summary:
public
Rename the `BridgeProfiling` JS module to `Systrace`, since it's actually just
an API to Systrace markers.
This should make it clearer as we add more perf tooling.
Reviewed By: jspahrsummers
Differential Revision: D2734001
fb-gh-sync-id: 642848fa7340c545067f2a7cf5cef8af1c8a69a2
Summary:
Functions from the path module return paths with the native file system path separator. generateAssetModule is using path.join and path.dirname to generate httpServerLocation. That means that on Windows systems, the generated URL path has backslashes rather than forward slashes which breaks the app's ability to retrieve image assets using require('./image.png'). This change fixes this by checking path.sep and replacing backslashes with slashes on systems that require it.
Closes https://github.com/facebook/react-native/pull/4416
Reviewed By: svcscm
Differential Revision: D2740529
Pulled By: mkonicek
fb-gh-sync-id: edae0f6762c7dc1db7af078209e38a2feab1e0a1
Summary:
Needed to support tagged template literals (which are already enabled in babel). Not having this helper means we get a runtime crash.
Closes https://github.com/facebook/react-native/pull/4680
Reviewed By: svcscm
Differential Revision: D2740233
Pulled By: spicyj
fb-gh-sync-id: 12729f670b7942ad7a04bd50ae1eca35d2b1e410
Summary:
public
Introduce a new Polyfill module to load bundles. This polyfill contains the function to which System.import gets transformed into. It works similarly to require in the way it's registered. It keeps track of the bundles that have ever been requested using promises, either fulfilled or not. The use of promises makes the implementation quite easy as we don't need to differenciate whether the request has been started or not.
There're a couple of follow up steps that still need to get done:
- Included this polyfill on the ones we automatically include on the bundle.
- Modify the transform to include the modules the user is actually requesting and pipe that through loadBundles so that the promise, once resolved, has the ordered list of modules the user requested.
- Implement the actual native code that loads a bundle. This shouldn't be that taught as native will be able to assume it will never receive the same request twice.
Reviewed By: davidaurelio
Differential Revision: D2727241
fb-gh-sync-id: 317d80754783caf43f10c71a34a4558a4d298d45
Summary:
ES6 modules export an object with a property called `default`. See Babel itself for how this is handled: b5b7e346a0
Closes https://github.com/facebook/react-native/pull/4513
Reviewed By: svcscm
Differential Revision: D2715512
Pulled By: mkonicek
fb-gh-sync-id: 40e5ea35adcdb66806a4895578d637cd72538619
Summary:
Adds support for multiple packager servers, which could be used to hot-reload dependencies in response to a change in the `cacheVersion`.
Currently, there is no way to:
- Create multiple `ReactPackager` servers.
- Instantiate more than one `FileWatcher` constructor (due to the "single instance" invariant).
public
Reviewed By: martinbigio
Differential Revision: D2713455
fb-gh-sync-id: 9be0f0cb2b846baf088d0cf14650cc8b9e950815
Summary: fixes https://github.com/facebook/react-native/issues/3997
the root cause is in
Mon, 09 Nov 2015 13:22:47 GMT ReactNativePackager:SocketServer uncaught error Error: listen EACCES C:\Users\donald\AppData\Local\Temp\react-packager-9248a9803ac72b509b389b456696850d
This means that the socket server cannot create the socket.
cfr https://gist.github.com/domenic/2790533 the socket name is not a valid windows socket name.
Closes https://github.com/facebook/react-native/pull/4071
Reviewed By: mkonicek
Differential Revision: D2699546
Pulled By: davidaurelio
fb-gh-sync-id: 6c6494c14c42bb17506b8559001419c9f85e91e3
Summary: Extracts the module system from the list of dependencies and adds it back to the bundling process.
Unbundling and Prepack has their own module systems. jest does as well. This is not normally part of the resolver, nor polyfills.
In fact, I think we'll eventually start treating polyfills as normal modules just like core-js.
The prelude is the weird part right now but I think that we'll eventually move the DEV flag to be module level instead of global and we can just get rid of this prelude.
public
Reviewed By: davidaurelio
Differential Revision: D2693701
fb-gh-sync-id: a59ccda0fa15fcfcda52897e8290805eed1b92b3
Summary: React Native is a lot more powerful an environment than the browser, so we need an alternate mapping, as specified [here](https://github.com/defunctzombie/node-browser-resolve#browser-field)
An example:
```js
{
"browser": {
"./lib/server": false
},
"react-native": {
"dgram": "react-native-udp",
"fs": "react-native-level-fs"
},
"chromeapp": {
"dgram": "chrome-dgram",
"fs": "level-filesystem"
}
}
```
on the other hand, if "react-native" is not present in package.json, you should fall back to "browser"
other than the one (nesting) test added, the tests are unchanged, just done for both "react-native" and "browser"
(I've implemented [react-native-udp](https://npmjs.org/package/react-native-udp) and [react-native-level-fs](https://npmjs.org/package/react-native-level-fs), but they obviously don't belong in the traditional "browser" field as they won't run anywhere except in React Native.)
Closes https://github.com/facebook/react-native/pull/2208
Reviewed By: svcscm
Differential Revision: D2691236
Pulled By: vjeux
fb-gh-sync-id: 34041ed50bda4ec07f31d1dc50dcdfa428af2512
Summary: public
Adding the babel helpers that are necessary to support ES2015 imports.
Fixes: https://gist.github.com/ehd/49cb2465df9da6b39710
Reviewed By: mkonicek
Differential Revision: D2690772
fb-gh-sync-id: b1b6c0c048bad809a5c58cdd0a2cbeaa11c72ea7
Summary: public
Show modules' dependencies and time to load.
Reviewed By: davidaurelio
Differential Revision: D2603245
fb-gh-sync-id: a1d5067a8522b908b87fdfdd51ff4c4fdbc2edfc
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: Manually resolve all default Babel plugins. `babel.transform` will attempt to resolve all base plugins relative to the file it's compiling. This makes sure that we're using the plugins installed in the react-native package.
**NOTE:** Haven't tested this. Please don't merge until Travis has done CI.
Closes https://github.com/facebook/react-native/pull/4248
Reviewed By: svcscm
Differential Revision: D2679651
Pulled By: davidaurelio
fb-gh-sync-id: 0cdef1e738ba28c09c811432a71047f80540ed7b
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
The recent change to move babelhelpers out of the module broke the extends method.
Reviewed By: spicyj
Differential Revision: D2656448
fb-gh-sync-id: 633433deea00ecb140afbb732bff0599e67b4d41
Summary: public
The inline-requires transform (from `fbjs-scripts`) is only used for oss tests, and wasn't updated, fix it.
Reviewed By: mkonicek
Differential Revision: D2641711
fb-gh-sync-id: 90a084082b9c55c5bcb776346f4655451a8a61f7
Summary: public
Fixes#4055
Babel is failing to find the plugins when running scripts with the full path,
cd into the folder before starting the packager as a workaround.
Reviewed By: vjeux
Differential Revision: D2638529
fb-gh-sync-id: b57151d3091d56a2c070692fb6296184a8fc62de
Martin Konicek
David Aurelio
Martín Bigio
Janic Duplessis
Pieter De Baets
Jan Kassens
Emil Sjölander
Christoph Pojer
Kyle Corbitt
Kelvin De Moya
Henrik Kok Jørgensen
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
David Anderson
Thomas Parslow
Brian Leonard
Mike Armstrong
Bram
Sebastian Markbage
Mark Vayngrib
Sebastian McKenzie
Giampaolo Bellavite