Summary:
I suggest we grab our own version of worker-farm, since there are a few changes we'd like to do. There are two reasons for forking:
* the original project does not seem maintained anymore, with a PR remaining unanswered (https://github.com/rvagg/node-worker-farm/pull/42);
* we don't need to keep the level of genericity of the original project: for example, we don't need the option `maxConcurrentCallsPerWorker`, that we always keep to one.
Forking gives us opportunity to simplify the code for our use case. Later on we could reuse it for other projects such as `jest`.
A few things we'd like to do:
* remove special node options from the forks, such as `--inspect`, or even, allow adding special options (if you want to debug a worker specifically for example);
* allow us to pipe `stdout` and `stderr` instead of having transform spit stuff out to the parent process output;
* remove code managing `maxConcurrentCallsPerWorker` and clean up the code in general;
* add `flow` typing.
Reviewed By: davidaurelio
Differential Revision: D4993300
fbshipit-source-id: 10f0c2a18b010c2a8b2e2afebcb3aab3504d7923
Summary: `no-alert` doesn’t play nice with flow type spreads. We don’t need it for node, anyway.
Reviewed By: jeanlauliac
Differential Revision: D4993096
fbshipit-source-id: 95785843d3263520c063a43864c8053cbaa5083d
Summary:
`declareOpts` prevents strong Flow typing, and promotes default values, that may be different from a function to another (my goal is to remove defaults from the whole codebase except perhaps the public API). This changeset replaces it by Flow types and fixes callsites to be explicit on values.
This is the last callsite of `declareOpts` so I'll remove it, in a separate diff.
Reviewed By: cpojer
Differential Revision: D4970650
fbshipit-source-id: e5ea2e06febde892d28c9dc59dc2920d4033bb01
Summary: Separates the polyfills used for node.js from the configuration of `babel-register`, to make pretransforming packager before invoking it easier.
Reviewed By: cpojer
Differential Revision: D4978047
fbshipit-source-id: 45d3d49d0a714a8257be8d244a01e41b68bbce3d
Summary: Fixes support for haste packages in `ModuleGraph`. As `HasteMap` is no longer used for anything else, we can probably strip it down completely.
Reviewed By: cpojer
Differential Revision: D4967367
fbshipit-source-id: d40cbe46c1e8b05690c0a2c71955479c28607c01
Summary: deduplicates / unifies types for source maps across the code base
Reviewed By: jeanlauliac
Differential Revision: D4955924
fbshipit-source-id: 25cb71031dce835dd7d2bc1c27d6b20050906e81
Summary:
Two things in there:
* Using `base64` was kinda broken, as it can contain slashes, invalid in file names. It would still work however because it would just create a second level folder when doing `mkdirp`. Still I think it's better to fix that correctness.
* Include the UID in the hash, so that different users have different folders for sure, and that we reduce potiential permissions issues. `tmpdir()` already returns a folder that's user-specific on OS X, but this is not a guarantee on all platforms.
Reviewed By: cpojer
Differential Revision: D4969856
fbshipit-source-id: 4a9be35104ac9698edf2c84c58d395ee171ce2a8
Summary: Oftentimes packager stalls for several seconds after requiring a bundle, because it's busy cleaning up old cache files. We shouldn't do that when, for example, we just restarted packager. This changeset stores the micro-timestamp of the last collection so that we don't waste time next time.
Reviewed By: cpojer
Differential Revision: D4969832
fbshipit-source-id: 3aa0495b18d5a8efa1b8f87dbf7a40b0673fd9fd
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:
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
Jean Lauliac
Andres Suarez
David Aurelio
cpojer
Lukas Piatkowski
Karol Kuczmarski
Ashok Menon
Alex Kring
Christoph Pojer