Summary: Adds a stronger type for the inline plugin to help with future refactors
Reviewed By: jeanlauliac
Differential Revision: D4945842
fbshipit-source-id: f9bde75bf47271d80d2420d985a6a5609cee8952
Summary: Changes the contract for `getTransformOptions` so that it has to return a promises. That allows call sites to get rid of special logic / wrapping.
Reviewed By: jeanlauliac
Differential Revision: D4905959
fbshipit-source-id: c7d434c0766984e25987de1d769594e7c922d691
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:
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: 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:
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
