Summary:
The existing resolution logic of assets:
* goes over all the files of the asset's directory for every resolution request;
* duplicates the parsing logic of `AssetPaths` by building up a custom regex for each resolution request.
This changeset proposes to tweak this by building an index for each particular directory in which we're looking for assets, so that we don't have to crawl a single directory twice, and so that it reuses the logic of `AssetPaths.tryParse()` for determining variants.
Reviewed By: davidaurelio
Differential Revision: D5062435
fbshipit-source-id: 708fc5612f57b14565499fad741701269438c806
Summary: Add Flow types, revealing a few problems, such as `isHaste` having the wrong return value in the "pseudo-mocks". But since the buck worker is in fact working, I guess these functions were never called... The point of typing this file is that I'm going to start aggressively pruning dead code in `node-haste` and hopefully, eventually, get rid of `Moduleish` and `Packageish`.
Reviewed By: davidaurelio
Differential Revision: D5052379
fbshipit-source-id: dab3f18f05fcf43fbbc48b589170b1cf367d6a48
Summary: I stumbled on this while refactoring that function, and i realised that, I believe it doesn't make sense to take into account the platform extension of the "potiential" file path. The reason is, if you try to require "foo.ios.png", the returned asset name would be "foo", and thus we'd try to find "foo.${ext}.png" where `ext` could actually be `android` or anything else! So it's confusing. There's no reason we should allow callsites to specify platform anyway I think. With this changeset we're not losing any functionality, but it might require people to fix some incorrect callsites.
Reviewed By: cpojer
Differential Revision: D5051791
fbshipit-source-id: 2a1ec7a8bfa6791b6016213305a72bc0b81f23b9
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:
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: 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: 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 moves the `src` directory one level up and removes the `react-packager` folder. Personally, I always disliked this indirection. I'm reorganizing some things in RNP, so this seems to make sense.
Not sure if I forgot to update any paths. Can anyone advice if there are more places that need change?
Reviewed By: jeanlauliac
Differential Revision: D4487867
fbshipit-source-id: d63f9c79d6238300df9632d2e6a4e6a4196d5ccb
Jean Lauliac
David Aurelio
Christoph Pojer