Summary:
<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->
**Summary**
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
Fixes#114 Learn more button links to a page that doesn't exist. This fixes both Learn more and Getting Starting buttons according to the comment in the issue.
**Test plan**
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->
Closes https://github.com/facebook/metro/pull/121
Differential Revision: D6719758
Pulled By: rafeca
fbshipit-source-id: 9647affacdda3c04b1e180fa95c1da28a51c0926
Summary:
**Summary**
Metro used to have support for "asset plugins", which allowed developers to specify arbitrary JS modules that could export a function for adding more fields to asset data objects. Some of this functionality was removed in the delta bundler work -- this PR adds it back.
**Test plan**
Made existing unit tests pass and added unit tests to test asset plugin behavior. Also tested E2E in a React Native project by adding `assetPlugin=/path/to/pluginModule` to a JS bundle URL and ensuring that the plugin ran.
Closes https://github.com/facebook/metro/pull/118
Differential Revision: D6711094
Pulled By: rafeca
fbshipit-source-id: f42c54cfd11bac5103194f85083084eef25fa3cd
Summary: This changeset tweaks the prelude so as to avoid overriding `process.env` if it already exists, and add tests to verify this behavior. This is useful when a bundle is loaded in a context that already provides a global `process` somehow, ex. Electron/Node.js. We still do want to override `NODE_ENV` in that case so as to have consistency with constant inlining.
Reviewed By: rafeca
Differential Revision: D6702441
fbshipit-source-id: 69dd9ba2303a43db151cbe1877f01e38d45b05b9
Summary: Next step would be to move the error handling out of this module so that we don't depend on `TModule` at all anymore. Once this is done, the module can be extracted as `metro-resolve`, and we can potentially reuse it for jest, etc.
Reviewed By: davidaurelio
Differential Revision: D6660540
fbshipit-source-id: dd0612bec6b526f9ab52cc2e162b6977e2b1670f
Summary:
**Summary**
Just noticed this link in the docs is pointing to the Jest help page - presumably a remnant from project boilerplate or copypasta :)
**Test plan**
Docs update only
Closes https://github.com/facebook/metro/pull/113
Differential Revision: D6668584
Pulled By: rafeca
fbshipit-source-id: b20b952677d1a088a8adc5576a70afb2bb624ae1
Summary:
**Summary**
Metro crashed with "Allocation failed - JavaScript heap out of memory" when trying to build a project with a lot of assets. (Repro: https://github.com/fson/metro-out-of-memory, `yarn start` and open the app.)
By looking at a heap snapshot, I found out the reason was that `node-haste` was reading the contents of asset files and parsing them in search of the `providesModule` docblock field, although it should only do this for source files. I fixed this by checking that `isHaste()` evaluates to `true` before attempting to read the docblock. (`AssetModule` always returns `false` for `isHaste()`.)
**Test plan**
* Ran the [repro](https://github.com/fson/metro-out-of-memory) before the fix. It crashed with `FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory`
* Heap snapshot: <img width="1440" alt="screen shot 2018-01-03 at 17 31 53" src="https://user-images.githubusercontent.com/497214/34571809-33ee8dfc-f178-11e7-93f9-3fd80e62c188.png">
* After implementing the fix, ensured that the process didn't crash anymore and the heap didn't grow significantly during the build:
Closes https://github.com/facebook/metro/pull/112
Reviewed By: jeanlauliac
Differential Revision: D6660719
Pulled By: rafeca
fbshipit-source-id: d4d8d4445e75274c65f6a52027d878041f1c9a33
Summary:
As reported in https://github.com/facebook/metro/issues/109, the sourcemaps generated by metro are including the binary data of all the assets, which adds a lot of overhead and is not useful at all.
This commit removes the assets contents from the sourcemaps to fix https://github.com/facebook/metro/issues/109
Reviewed By: jeanlauliac
Differential Revision: D6649741
fbshipit-source-id: 8b09d429a1aa8d487557c22440bfa73ae55d03bd
Summary: Finally we can extract this function out, that remove any remaining dependency on the `TModule` generics and the like. Next steps are to push Metro-specific concepts out of the `resolveDependency` function and out of the module completely, after which the module will be ready to have its own unit tests, and be split into a `metro-resolve`.
Reviewed By: cpojer
Differential Revision: D6645333
fbshipit-source-id: a7915d646f888c29b410bf211f2e2bc4ec157676
Summary: This changeset alters the Haste resolution logic to be in sync with the new refactored pieces (resolveFile, etc.) Next steps involve extracting this function outside of the class so as to reduce the surface API and promote composability.
Reviewed By: cpojer
Differential Revision: D6645302
fbshipit-source-id: 6ee00fb52025cc0d332e57f837b46e8323faf6f4
Summary: In a further diff, I'll add cases where this error may be thrown at a higher level than the `resolveFileOrDir` function. So we need to move the handler and wrapping logic up the stack, that doesn't have any difference in practice.
Reviewed By: cpojer
Differential Revision: D6642475
fbshipit-source-id: 6b746386a170bfc167a9b50d9786fbb98c920c6d
Summary:
This is part of the efforts to clean up and extract the resolution logic. In this diff, the haste resolution is moved as part of the main resolution function rather than having 2 separate top-level functions. The reason for doing this is that logic is duplicated otherwise, making the already complex code harder to follow still. An example of duplicated logic is the call to `isRelativeImport`, that is done both in ResolutionRequest and ModuleResolution's node resolver. In that case, we never want to use Haste. Another duplication is the redirect of requires of package/haste names. With this changeset it is done in a single place at the beginning of the algo.
This changeset causes slight changes in behaviors. For example, consider `require('Foo/')`. A lookup of `Foo` would be done in the package `browser` field for a potential redirect. With this new code, we'll only look for `Foo/` in the redirect map. My opinion is that this is for the better, as this uniformize the way it works with Node.js `node_module` packages, making resolution more predictable. We should, additionally, actively strive to get rid of trailing slashes anywhere they might be in RN as they bring no apparent technical feature, but more confusion (I might be missing context, naturally).
Next steps will be to clean up `_resolveHasteDependency` completely, removing the callsite `try..catch` in favor of saner conditionals, and enforcing Haste packages to resolve if they exist (right now if a Haste package is found but corrupted, we just continue merrily trying to resolve the module with the rest of the logic; we should hash-crash instead, same as has been done for `resolvePackage`).
Reviewed By: cpojer
Differential Revision: D6642347
fbshipit-source-id: 2f40575b35916b644f342e0267c465a89bee202c
Peter van der Zee
Rafael Oleza
codypearce
Adam Ernst
Maël Nison
James Ide
Jean Lauliac
Miguel Jimenez Esun
glevi@fb.com
Rich Gilbank
Ville Immonen
