Summary: This installs the 2.0 version of node-haste, removes the DependencyResolver and fixes up all the tests.
Reviewed By: davidaurelio
Differential Revision: D2943416
fb-gh-sync-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
shipit-source-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
Summary:As discussed here #1194 . This add an getter the default handler, so that custom handler can be added (monkey patch?) without overwriting the default handler
Closes https://github.com/facebook/react-native/pull/5575
Differential Revision: D2948994
fb-gh-sync-id: 2b6d1619cfe68f78b326c6d232b9bf57c489c45d
shipit-source-id: 2b6d1619cfe68f78b326c6d232b9bf57c489c45d
Summary: Users don't know what an accept callback is. Lets be more explicit on what type of modules we currently support hot loading.
Reviewed By: weicool
Differential Revision: D2945438
fb-gh-sync-id: d0fc228ab23833371f8fbbd86ed18e81c8ba0ebf
shipit-source-id: d0fc228ab23833371f8fbbd86ed18e81c8ba0ebf
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: javache
fb-gh-sync-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
shipit-source-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: davidaurelio
fb-gh-sync-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
shipit-source-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
Summary:
public
Remove the unused feature for async dependencies / bundle layouts. We can bring it back later, if needed.
Reviewed By: cpojer
Differential Revision: D2916543
fb-gh-sync-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
shipit-source-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
Summary:
Now that String.prototype.includes is there, we should remove the .contains one which has not been standardized.
For fb reviewers, this needs to land after D2910339 which updates internal callsites.
Closes https://github.com/facebook/react-native/pull/5794
Reviewed By: svcscm
Differential Revision: D2910855
Pulled By: vjeux
fb-gh-sync-id: 8fd216222385f038995d1ed10e8a2c4c34c7e928
Summary:
Rather than specifying Babel plugins in the `.babelrc` packaged with react-native, leverage a Babel preset to define the plugins (https://github.com/exponentjs/babel-preset-react-native).
This allows for a much better user experience for those who want (or need) to override options in their project's `.babelrc`.
Prior to this PR, if a user wanted to use a custom babel-plugin (or a custom set of babel plugins), they'd have either 1) manually override the `.babelrc` in the react-packager directory (or fork RN), or 2) specify a custom transformer to use when running the packager that loaded their own `.babelrc`. Note - the custom transformer was necessary because without it, RN's `.babelrc` options would supersede the options defined in the project's `.babelrc`...potentially causing issues with plugin ordering.
This PR makes the transformer check for the existence of a project-level `.babelrc`, and if it it's there, it _doesn't_ use the react-native `.babelrc`. This prevents any oddities with Babel plug
Closes https://github.com/facebook/react-native/pull/5214
Reviewed By: davidaurelio
Differential Revision: D2881814
Pulled By: martinbigio
fb-gh-sync-id: 4168144b7a365fae62bbeed094d8a03a48b4798c
Summary:
node-haste shouldn't ever call process.exit and should leave it up to clients to shut down properly. This change just moves it out into the `Resolver` class – I'll leave it up to David and Martin to improve error handling for the rn packager :)
public
Reviewed By: davidaurelio
Differential Revision: D2889908
fb-gh-sync-id: 6f03162c44d89e268891ef71c8db784a6f2e081d
Summary:
The FS as seen by an instance of a dependency graph is useful for clients of node-haste. This provides an accessor to fastfs so that the partial view of the filesystem can be queried. I was thinking of splitting out the fastfs creation to outside the constructor but the necessary refactoring doesn't seem worth it. The fastfs is intrinsically tied to the dependency graph and the `DependencyGraph` instance is meant to be a base-class for clients anyway. Both in react-packager and jest we are wrapping it with higher-level client specific containers, Resolver and HasteResolver respectively.
public
Reviewed By: davidaurelio
Differential Revision: D2885217
fb-gh-sync-id: 47a408b2682516bee9d6a4e6c61b9063817aaf22
Summary:
public
At the moment, when the user changes a file we end up pulling the dependencies of the entry point to build the bundle. This could take a long time if the bundle is big. To avoid it, lets introduce a new parameter to `getDependencies` to be able to avoid processing the modules recursively and reuse the resolution responseto build the bundle.
Reviewed By: davidaurelio
Differential Revision: D2862850
fb-gh-sync-id: b8ae2b811a8ae9aec5612f9655d1c762671ce730
Summary:
public
Adds the new polyfill to the relevant tests (Resolver/BundlesLayout)
Reviewed By: martinbigio
Differential Revision: D2878697
fb-gh-sync-id: 9681f16dd19a0b337aac63101450c703bf387346
Summary:
public
The reverted change doesn’t play nice with inline requires, let’s revert it for now.
I will bring it back after fixing it or adapting inline requires
Reviewed By: martinbigio
Differential Revision: D2854771
fb-gh-sync-id: 32fdbf8ad51240a9075b26502decb6328eed4b29
Summary:
public
Adds two feature to the require implementation for unbundled code:
- Ports Systrace from `require.js`
- Prevents already loaded modules from being overwritten by repeated calls to `nativeRequire` with the same ID
Reviewed By: martinbigio
Differential Revision: D2850345
fb-gh-sync-id: 122e2d5d4a64b2e868d4cf6e5079810f59b1db18
Summary:
public
This adds the ability to load “unbundles” in RN android apps. Unbundles are created by invoking the packager with the `unbundle` command rather than `bundle`.
The code detects usage of an “unbundle” by checking for the existence of a specific asset.
Reviewed By: astreet
Differential Revision: D2739596
fb-gh-sync-id: d0813c003fe0fa7b47798b970f56707079bfa5d7
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:
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
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
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
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:
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
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
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:
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:
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:
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:
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: 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: 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: 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
