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
Summary: This improves the error message by providing line/column so we can identify errors encountered in https://github.com/facebook/metro/issues/65 easier. Also provide additional fields so we can better format that later on.
Reviewed By: cpojer
Differential Revision: D6641909
fbshipit-source-id: 0372da6b2fb51010b42ab906fc40b528b1483532
Summary:
The spec doesn't say the `browser` field should actually generate a replacement for the main *file*, just that it provides an alternative main: https://github.com/defunctzombie/package-browser-field-spec#alternate-main---basic
We also don't have any test covering this behavior. Any package relying on this behavior should be fixed to have a redirection of the main *file* in addition to their `main` *field*.
This is part of an effort to cleanup the way we do redirections. Eventually this will be part of the resolution module, not `Package.js`.
Reviewed By: davidaurelio
Differential Revision: D6611894
fbshipit-source-id: 0186aa23df2a9183d895ea02b5fd3b2b7339dc76
Summary: This is one of the first step towards a generic and composable resolution algorithm. We shall get rid of `TModule` as it's an abstraction that doesn't bring us any benefit in the resolution algo, and we actually want to get rid of `Module.js` eventually. This changeset gets rid of `TModule` up to the place where I already got rid of the exception-based control flow mechanism. Next steps are to push the boundaries higher up both for error handling, and for removing `TModule`.
Reviewed By: mjesun
Differential Revision: D6603157
fbshipit-source-id: 551e9ccd93628f45452148ed40a817bdde3740ea
Summary: I want to get rid of `TModule` and stuff so that we can eventually reunite this with `jest-resolve`. This is a continuation of the cleanup I started a long time ago.
Reviewed By: davidaurelio
Differential Revision: D6601657
fbshipit-source-id: 62c1806783323ee50e9a09146c73006c721eb891
Summary:
On D6248242, runBeforeMainModule was changed to `getModulesRunBeforeMainModule`, but the entry point used by opensource to build prod bundles was not updated. We couldn't catch this since we don't use this codepath internally
Fixes https://github.com/facebook/metro/issues/73
Reviewed By: mjesun
Differential Revision: D6556097
fbshipit-source-id: 889eaf825c7c3cdebe1ca4fc9831020a4a7d56dc
Summary:
Addresses a performance regression introduced by automatic linting: Compound assignment operators are much slower than keeping assignment separate on `let` bindings in certain versions of v8.
This reverts the relevant changes and configures eslint to *disallow* these operators explicitly in `metro-source-map`.
Reviewed By: mjesun
Differential Revision: D6520485
fbshipit-source-id: 16f35f5cd691ce6b1924480cbc30fbaa1275f730
Summary:
**Summary**
`createModuleIdFactory` is already used in `metro` internally, but is currently always a fixed function.
This enables `metro.runBuild()` to be run with a custom module ID factory.
One use case: building a base bundle, on top of which other application-specific bundles could reference modules in the base. The application-specific IDs need to not conflict with those in the base bundle, and all references to modules in the base must resolve to the correct ID in the base bundle. A custom ID factory can make all this possible.
**Test plan**
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->
Using `metro.runBuild(...)` with these changes, I was able to substitute in a custom ID factory
```javascript
const fs = require('fs')
const metro = require('metro')
const baseManifestFileContents = JSON.parse(fs.readFileSync('./baseManifest.json'))
// baseManifest looks like:
// { "modules": { ...
// "react/index.js": { "id": 12 },
// "react/cjs/react.production.min.js": { "id": 13 }, ... } }
const opts = {
dev: false,
entry: 'index.js',
out: './out.bundle',
platform: 'ios',
projectRoots: ['.', 'node_modules'],
config: {
createModuleIdFactory: createModuleIdFactory(baseManifestFileContents)
}
}
metro.runBuild(opts)
// Creates a sample custom ID factory
function createModuleIdFactory(manifestFileContents) {
return function createModuleIdFactory() {
const fileToIdMap = new Map()
let nextId = manifestFileContents ? getNextIdAfterBaseManifest(manifestFileContents) : 0
return path => {
const sourcePath = path
.replace(process.cwd() + '/node_modules/', '')
.replace(process.cwd(), '.')
// If module is in the base manifest, return its ID
if (manifestFileContents && manifestFileContents.modules[sourcePath]) {
return manifestFileContents.modules[sourcePath].id
}
// Otherwise, get it from the map or create a new ID
if (!fileToIdMap.has(path)) {
fileToIdMap.set(path, nextId)
nextId += 1
}
return fileToIdMap.get(path)
}
}
function getNextIdAfterBaseManifest(manifestFileContents) {
return Object.keys(manifestFileContents.modules).reduce((id, key) => {
if (manifestFileContents.modules[key].id > id) {
return manifestFileContents.modules[key].id
}
return id
}, 0) + 1
}
}
```
With the sample module ID factory above, the output looks like the following, where defined module IDs start at a higher number to avoid the base module IDs, but may depend on modules in the base bundle (lower numbers).
```javascript
...
__d(function(r,o,t,i,n){t.exports=r.ErrorUtils},551,[]);
__d(function(n,t,o,r,u){'use strict';var e,c=t(u[0]);e=c.now?function(){return c.now()}:function(){return Date.now()},o.exports=e},552,[553]);
...
__d(function(e,t,r,s,l){'use strict'; ...},564,[18,565,27]);
...
```
Closes https://github.com/facebook/metro/pull/100
Reviewed By: mjesun
Differential Revision: D6508351
Pulled By: rafeca
fbshipit-source-id: f2cfe5c373a6c83c8ae6c526435538633a7c9c2a
Summary:
With this, we do all the transformation and wrapping of files inside the workers, which mean faster initial builds (because parallelization and caching), and more legacy code that can be removed (see the following diff).
I've done some tests locally, and while the initial builds are slightly faster, the increase is not super substantial (the big win was in the diff were I moved the wrapping of JS files, in this diff only the assets transformation has speed up).
The most important thing that this diff enables is the possibility of doing the minification of modules also in the worker. This will mean that we can cache minified files and prod builds will get significantly faster - almost as fast as development builds (this will be relevant mainly for the opensource community).
Reviewed By: davidaurelio
Differential Revision: D6439144
fbshipit-source-id: ba2200569a668fcbe68dbfa2b3b60b3db6673326
Summary: This fixes https://github.com/facebook/metro/issues/99, which causes issues when metro tries to build files that are ignored by babel (if babel transformer ignores a file, it returns a null AST, which makes the collectDependencies logic break).
Reviewed By: mjesun
Differential Revision: D6466878
fbshipit-source-id: b5030e03775b982958a0b9204f4efccc8940ae4d
Summary: I'm working on getting CI to pass. As a first step, I'll upgrade the lerna setup to use Yarn's workspaces (when yarn is run from the Metro root) as well as upgrading Flow to the same version we use in xplat. I also copied over the Jest type definitions. This should fix all type errors for a start.
Reviewed By: davidaurelio
Differential Revision: D6361276
fbshipit-source-id: 4e8661b7d5fe4e3f6dd1e6923891bd2d23c9b4db
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? -->
It is currently not possible to resolve specific module imports (such as `react-native/Libraries/Image/AssetRegistry` using forward slashes as folder separators) using a custom mapping defined in `extraNodeModules` on Windows. This PR solves this issue by normalizing module names to use platform-specific folder separators before splitting the module name using `path.sep` as separators.
**Test plan**
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->
We use `extraNodeModules` to create a mapping between `react-native` and a forked and scoped version of react-native (i.e. `scope/react-native`). If we import a specific file from react-native (such as [`react-native/Libraries/Image/AssetRegistry`](https://github.com/facebook/react-native/blob/master/local-cli/core/Constants.js), which gets referenced when importing image assets), `ModuleResolution.js` is not able to extract the first folder name on Windows. This first folder name is the name of the module (`react-native` in the previous example) and is used to query `extraNodeModules` for possible matches. It is not able to find this folder name because the module name is split using `path.sep` as a separator, which is `'\\'` on Windows. Most module names use forward slashes as folder separators. The solution is to normalize `toModuleName` before we split on `path.sep`.
Closes https://github.com/facebook/metro-bundler/pull/89
Differential Revision: D6312391
Pulled By: jeanlauliac
fbshipit-source-id: 920c52633e8c9584ecb2bdd309dc4a8516c3199b
Summary:
Uglify@3.1.7 is causing some perf issues (more specifically, this commit: 5b4b07e9a7) that are impacting TTI on RN views and increased memory usage.
More specifically, code like:
```
function nonTrivialFn(pre) {
return pre + Math.random();
}
function hotFunctionCalledALotOfTimes(num) {
return nonTrivialFn(num + Math.random());
}
hotFunctionCalledALotOfTimes(3);
hotFunctionCalledALotOfTimes(5);
```
in v3.1.7 gets converted to:
```
function hotFunctionCalledALotOfTimes(num){
return function(pre) {
return pre + Math.random();
}(num + Math.random())
}
hotFunctionCalledALotOfTimes(3);
hotFunctionCalledALotOfTimes(5);
```
This causes a function creation each time `hotFunctionCalledALotOfTimes` is called.
By comparison, in v3.1.6, that previous code was converted to:
```
function nonTrivialFn(pre){
return pre + Math.random()
}
function hotFunctionCalledALotOfTimes(num){
return nonTrivialFn(num + Math.random())
}
hotFunctionCalledALotOfTimes(3);
hotFunctionCalledALotOfTimes(5);
```
Reviewed By: jeanlauliac, alexeylang
Differential Revision: D6296740
fbshipit-source-id: b3988d886e607103ec3ae6b9763b2f0411a8aa3c
Summary:
`metro-bundler` v0.21 contains a rewritten bundling mechanism, with simplified logic and much faster rebuild times, called delta bundler. This release contains a couple of breaking changes:
* Now, when using a custom transformer, the list of additional babel plugins to apply are passed to the `transform()` method. These are used in non-dev mode for optimization purposes (Check 367a5f5db8 (diff-40653f0c822ac59a5af13d5b4ab31d84) to see how to handle them from the transformer).
* Now, when using a custom transformer outputting `rawMappings`, the transformer does not need to call the `compactMappings` method before returning (check d74685fd1d (diff-40653f0c822ac59a5af13d5b4ab31d84) for more info).
* We've removed support for two config parameters: `postProcessModules` and `postProcessBundleSourcemap`.
Reviewed By: davidaurelio
Differential Revision: D6186035
fbshipit-source-id: 242c5c2a954c6b9b6f339d345f888eaa44704579
Summary:
**Summary**
Minification fails or minified bundle may crash due to uglify-es bugs which have been fixed recently. See https://github.com/facebook/react-native/issues/16689
**Test plan**
Try to production bundle a project using ex-navigation, which fails with:
```
Maximum call stack size exceeded
```
Use this patch and see that bundling suceeds. There are also minified runtime errors solved by this change, see https://github.com/facebook/react-native/issues/16689 for more information.
Closes https://github.com/facebook/metro-bundler/pull/85
Reviewed By: mjesun
Differential Revision: D6259177
Pulled By: rafeca
fbshipit-source-id: 55987eb338b06938181c0da74d104d23eeb135b6
Summary:
This diff migrates Metro Bundler from `worker-farm` to `jest-worker`:
* Fully removes the custom patched `worker-farm` fork.
* Removes //a lot// of non-clear Flow types used to cast functions from callbacks to promises.
* Reduces cyclomatic complexity of the `Transformer` class by using `async`/`await`.
* Cleans all additional methods inside `JSTransformer/index.js`, by moving them to a single class and properly scoping them.
**Note:** this diff does not still enable the ability to bind files to workers by using `computeWorkerKey`; this will come at a later stage.
Reviewed By: davidaurelio
Differential Revision: D6247532
fbshipit-source-id: 51259360a5c15117996777a3be74b73b583f595e
Summary: To determine whether segment boundaries are properly covered by async imports rather than requires, we need to get knowledge about it higher up in the stack. This changeset exposes which of the dependencies are async as an array of indices within the `dependencies` array (I'd prefer avoiding duplicating the strings because they could get inconsistent, and I don't want to have 2 separate arrays of names either because we'd have to modify a bunch of stuff across the stack to support that).
Reviewed By: davidaurelio
Differential Revision: D6220236
fbshipit-source-id: 1ee36bc7c59f7f27e089f7771a24c45c8bd57b5d
Ville Immonen
Rafael Oleza
Jean Lauliac
Charles Dick
Miguel Jimenez Esun
Peter van der Zee
Burak Yigit Kaya
Brian Shin
Nat Mote
Maël Nison
Adam Ernst
David Aurelio
Adam Liechty
Marshall Roch
Christoph Nakazawa
cpojer
Benjamin Weggersen
Caleb Meredith
Andreas Amsenius
