Summary:
It was hard to type the resolution main algo, I had to put type annotations explicitely everywhere, otherwise Flow would get in some kind of loop and do weird errors. I think it's because the algo is recursive and Flow tries to infer types too deeply because of the generics.
Anyway, apart from that it's good to get this extra type security in the few other places. We require Node v4 minimum, that according to the internets supports the `class` syntax without transform, and I verified that inheriting from `Map` actually works as expected.
Reviewed By: davidaurelio
Differential Revision: D5078023
fbshipit-source-id: 05dfc4acf5b07cdda8a7b36ec9cba216d1810643
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:
Not only is this function is building a custom Regex for every single file, but it's also duplicating some of the work of the inner function, that is already splitting up the platform/extension. This changeset refactors both function to have a more strict and legible logic to extract asset information. We extract the base name first, then we extract the resolution from it, instead of rematching platform and extension.
I stumbled on this while looking into refactoring the asset resolution logic of `ResolutionRequest#_loadAsAssetFile()`. The next step would be to reuse the exact same function for resolving assets instead of using a custom regex there as well.
Reviewed By: davidaurelio
Differential Revision: D5060589
fbshipit-source-id: b48d9a5d8e963be76cad5384c6bfb3e214a73587
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: I found myself a few times wanting that transform, that makes it slightly simpler to have bound method. So I propose we add it. Not a big deal though. Note it also allows static properties with the same syntax, that is handy.
Reviewed By: davidaurelio
Differential Revision: D5051579
fbshipit-source-id: 7ebf7c709bf52a30a525550c1eda1a6a2f7b8e1e
Summary: That's a bit of an experimental changeset, I wanted to experiment how we can track with more precision the resolution and this is what I come with. That allows us to know what has been tested if we canot find a match. It also uses a simpler control flow with early `return`s all across. Finally, this reflect the strategy I want to apply for the rest of the resolution. (Right now the error is still not great, as it may be deeply nested, as in the case of packages resolution.)
Reviewed By: davidaurelio
Differential Revision: D5044040
fbshipit-source-id: 2e256174506f80d90ee83175057666d530785788
Summary: I'm continuing my changes to avoid `lstat`-ing the folders when we don't really need to. That changeset in particular proposes to remove the check in `_loadAsDir`. The rationale is that right after that we try for the presence of the `package.json`. If that file exists, the folder necessarily exist so we can switch these two `if` blocks for sure without changing the logic. Finally, at the end we look for the "index" file. By removing the folder check, packager would now report "file `foo/index` does not exist" rather than "directory `foo` does not exist" if the folder does not exist. I think it's not much worse, especially as both of these are unhelpful for what I believe to be a large number of cases already anyway. Indeed, the whole algo is based on a series of try/catch, and only the very last try will see its error surfaced. But, most often, it'd be useful for earlier tries to be surfaced to the user. I do want to improve that; meanwhile, however, I sense it's not a big deal to remove that folder check for all these reasons. If you don't agree, I do have another proposition: we could catch errors generated by the last `_loadAsFile` call, and rethrow them as directory errors instead (if `dirExists` return `true`). That way, the call to `dirExists` would only happen in case of errors (but that could still happen quite a lot as a result).
Reviewed By: davidaurelio
Differential Revision: D5028341
fbshipit-source-id: 2d4c99c0f352b71599482aa529728559466b76fd
Summary: I think we don't really need to check the directory beforehand, the function to find asset will just return an empty array. As for the error message, I tried adding a require of an asset file somewhere, but due to the way the ResolutionRequest algo work, it generates a final error message that unrealted ("Directory ... does not exist", instead of the "asset does not exist"). I plan to revamp the way errors are handled such as the error message clearly identifies what file paths have been inspected.
Reviewed By: davidaurelio
Differential Revision: D5028118
fbshipit-source-id: 496472001c0a3d4192bfef4a0c8a0dc8a9a0fa82
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:
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: Some more synchronicity, one step at a time.
Reviewed By: davidaurelio
Differential Revision: D4756542
fbshipit-source-id: 0c56dbca61b3da764aa8d28e29c0e20b54de091e
Summary:
Absolute imports on Windows were broken, I'm not 100% sure when this happens but when I tested Exponent on Windows which uses `rn-cli.config.js` with
```js
getTransformOptions() {
return {
reactNativePath: path.resolve('./node_modules/react-native'),
reactPath: path.resolve('./node_modules/react'),
};
}
```
it seemed to use absolute paths for these modules.
I also tested absolute paths in node repl and it does work for absolute paths of different formats. `C:/root/test.js`, `/root/test.js`, `C:\root\test.js` all do resolve properly to the same module.
To fix this I resolve the absolute path using `path.resolve` on Windows. Noop on other platforms to avoid the overhead since it's not necessary.
**Test plan**
- Tested that it fixed the bug I had when running Exponent on Windows.
- Updated the absolute path test to use forward slashes since this is what happens in practice when using `getTransformOptions`. We can't test all cases on linux since adding the drive letter au
Closes https://github.com/facebook/react-native/pull/12530
Differential Revision: D4634699
Pulled By: jeanlauliac
fbshipit-source-id: 0cf6528069b79cba2e0f79f48f5a524d59b7091e
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
