Summary: It seems we don't need that one much anymore, as we have a FS-based cache for files, and removing the last callsites doesn't really change perf, as we have to read these files eventually (plus some of these are read from `HasteMap`, that I believe is already dead code).
Reviewed By: davidaurelio
Differential Revision: D4884220
fbshipit-source-id: 4cf59f16a6f0bdf275abe81e9de2f34816866bae
Summary:
Don't build js bundles for debug simulator build configurations
Motivation:
We have more than one debug build configuration that we run in the simulator, and none of them are exactly named 'Debug'. We want to establish the convention that any simulator build configuration containing the word 'Debug' will not build the react js bundles. We believe this is less intrusive to the developer.
Closes https://github.com/facebook/react-native/pull/13472
Differential Revision: D4890622
Pulled By: javache
fbshipit-source-id: 4c809551f64ad575335416de28887a90b0756de1
Summary:
Note: if this changeset causes some breakage, consider disabling rather than reverting. To disable, the call to `_preprocessPotentialDependencies` in `ResolutionRequest` can be removed.
It's a bit of an experiment. I couldn't see any particular regression caused by this, but I could see net improvement of the global cache performance, as it unlock much, much stronger batching: indeed, instead of discovering dependencies progressively, we synchronously figure out the list of all potential modules of a bundle, and kick-off cache fetching and/or transformations. So when it comes to fetching from the global cache, it'll do less requests, and each requests will ask for considerably more keys at a time.
Potential problem caused by this changeset: if a module's dependencies completely changed, then the first time we try to build the bundle it'll start transforming modules that we probably don't care at all anymore, spending precious CPU time for nothing. I've been thinking about it and I cannot see such a case happening much often. Even if it happens, it should not cause any bug or corruption, it would just take additional time.
Other potential problem: that this new code doesn't handle some types of edge cases. It's quite hard to figure out what could possibly break in the `ResolutionRequest` code (and I think it would benefit from a larger refactor). We do have a good test coverage for `DependencyGraph` and it seems to work smoothly, so I'm relatively confident we're not breaking edge cases.
Reviewed By: davidaurelio
Differential Revision: D4875467
fbshipit-source-id: 2dfcc755bec638d3d1c47862ec1de5220953e812
Summary: The original code wasn't very readable. Better with this change, I think.
Reviewed By: davidaurelio
Differential Revision: D4851335
fbshipit-source-id: 210309d4b727aff58bea48d0ab324256234cd941
Summary:
There is a bug with IP detection on Macs that have (1) multiple ethernet interfaces, (2) are using the second or third interface as their primary connection and (3) have extra loopback IPs configured (for example when running OpenVPN, running some Docker configurations or other more exotic applications). In those cases, automatic IP detection will falsely detect the IP as something like `127.94.0.1`, which will make it impossible to run debug builds from a physical device.
The underlying network configurations looks something similar to this (irrelevant parts omitted):
```
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet 127.94.0.1 netmask 0xff000000
nd6 options=201<PERFORMNUD,DAD>
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
ether xx:xx:xx:xx:xx:xx
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
Closes https://github.com/facebook/react-native/pull/13415
Differential Revision: D4859654
Pulled By: javache
fbshipit-source-id: 3c5d06201c48a2dfe1c274ff433423e5d7f2cded
Summary:
When running an app on a real iPhone in debug mode, I occasionally get issues when trying to load the js bundle and I suspect the issue is with xip.io (and it doesn't look like I'm the only one: https://github.com/facebook/react-native/issues/12786https://github.com/facebook/react-native/issues/9688#issuecomment-272591839). So I've added the ability to optionally disable the use of xip.io if an env variable `DISABLE_XIP` is set.
Add `export DISABLE_XIP=true` to the `Bundle React Native code and images` build phase. Run the app on a real iPhone and ensure that it can load the JS bundle from the host computers IP.
Closes https://github.com/facebook/react-native/pull/13326
Differential Revision: D4855719
Pulled By: ericvicenti
fbshipit-source-id: cb2e91291acadaa78ea302800b55c2e5388f6380
Summary: This removes the call to `HasteFS#matchFiles()`, that has linear complexity. Instead, we index all the files by directory from `HasteFS` once loaded, a linear operation. Then, we can filter files from a particular directory much quicker.
Reviewed By: davidaurelio
Differential Revision: D4826721
fbshipit-source-id: c31a0ed9a354dbc7f2dcd56179b859e491faa16c
Summary:
One of my changeset broke the "ModuleGraph" code without warning earlier because we are using `any`, that equivalent to having no typing at all. This changeset fixes the types so that `ResolutionRequest` is exactly what it actually is: a class usable for any `Module`-looking class, including the normal one, and the "ModuleGraph" one used for Buck builds. That way, the ModuleGraph's `Module` is typechecked against `Moduleish`.
Concretely this change mostly migrates the `Module` to its generic parameter counterpart `TModule` inside `ResolutionRequest`.
Reviewed By: kentaromiura
Differential Revision: D4826256
fbshipit-source-id: fcd7ca08ac6c35e4e9ca983e2aab260e352bcb4e
Summary: Adapts mocked / duplicated functionality from `node-haste` to match the new synchronous return types in the original.
Reviewed By: jeanlauliac
Differential Revision: D4819137
fbshipit-source-id: 183316adc3fae161ad9999bf72bccb8218ef8941
Summary:
Follow up to #13248 for iOS.
This pull request allows changing the default path to `cli` when running from Xcode environment. That is especially useful when debugging from a different location or... running `Haul`.
Set `export CLI_PATH=./node_modules/react-native/local-cli/cli.js` and run. Should use new path provided.
Closes https://github.com/facebook/react-native/pull/13264
Differential Revision: D4819059
Pulled By: ericvicenti
fbshipit-source-id: 4a6241823c0bc8f1fa16869bc872bdbe04df510f
Summary:
This PR depends on #13172
Packager events are mostly logged through the TerminalReporter by default (#13172 makes this configurable). But there are a few things that aren't passed through TerminalReporter.
- We [log a banner with some information about the port and what's going on](8c7b32d5f1/local-cli/server/server.js (L22-L32))
- Also [a message about looking for JS files](8c7b32d5f1/local-cli/server/server.js (L34-L38)) (not sure what that is for / if it is useful beyond telling the user what directory root they started the packager in, but that's another thing).
- If the packager fails to start, then [we log an error message](8c7b32d5f1/local-cli/server/server.js (L41-L61)).
This pull request changes those log messages to be handled by TerminalReporter. I tri
Closes https://github.com/facebook/react-native/pull/13209
Differential Revision: D4809759
Pulled By: davidaurelio
fbshipit-source-id: 2c427ec0c1accaf54bf6b2d1da882cd6bfaa7829
Summary: At FB we log errors into the error infra, and these errors are not actionnable for end users, so let's reduce the noise generated on the terminal. In the OSS case, people can simply add a handler in a TerminalReporter decorator, the same way we do internally (anyhow, I do not know of anyone using the global cache in OSS for now).
Reviewed By: davidaurelio
Differential Revision: D4762858
fbshipit-source-id: 880c02e175ae551df11b7ce273acc318222c46bf
Summary: Some more synchronicity, one step at a time.
Reviewed By: davidaurelio
Differential Revision: D4756542
fbshipit-source-id: 0c56dbca61b3da764aa8d28e29c0e20b54de091e
Summary: We want any exception thrown by `_getHasteName` to be captured by the promise instead of breaking the outer stack.
Reviewed By: davidaurelio
Differential Revision: D4754825
fbshipit-source-id: 173c7c8867da73efb198ed3159704d6fd0e7b87d
Summary: In case the sync function throws, it wouldn't be handled through the promise anymore, that is not what we want. So we revert that in this changeset.
Reviewed By: davidaurelio
Differential Revision: D4754740
fbshipit-source-id: 4da360f4b629bbdf9cd284389060429cc9259c2c
Jean Lauliac
Alex Kring
Christoph Pojer
cpojer
David Aurelio
Hilke Heremans
Jonathan Kim
Mike Grabowski
Tim Yung
Brent Vatne
Pieter De Baets
Lee Byron