Summary: Upgrades uglify to version 3 with (experimental) ES6 support turned on.
Reviewed By: jeanlauliac
Differential Revision: D5842410
fbshipit-source-id: 1c8ccea15785bc5bb1c68d7a83b75881432d0ce2
Summary:
This replaces `async/queue` with a hand-rolled queue that does not yield to the event loop if a unit of work can be run synchronously.
Anecdotally, this leads to a > 11x speedup for the graph traversal when all data is available synchronously, e.g. from an in-memory cache.
Reviewed By: jeanlauliac
Differential Revision: D5861763
fbshipit-source-id: f7cf5f916a13adf9ca418d7522cd2f19df596fba
Summary: Changes `GraphFn` to return a promise rather than taking a callback. This is more in line with call sites, which so far have been using `denodeify`.
Reviewed By: jeanlauliac
Differential Revision: D5857192
fbshipit-source-id: 61bbbef4fbf24b0b91c4a3008541eaa5a1af0f7a
Summary:
Changes `LoadFn` to be synchronous or return a promise, and `ResolveFn` to be synchronsous.
This makes for a nicer API, without losing the property of not yielding to the event loop for synchronous work.
Reviewed By: jeanlauliac
Differential Revision: D5855963
fbshipit-source-id: 4b3c3363f4e49a9890586462925e8e400872feb2
Summary: When running with node 8, the babel plugins `async-to-generator` and `syntax-trailing-function-commas` are unnecessary. Removing them makes runtime transpilation faster, and the resulting code is closer to the original (useful with debugging: less unmapped code areas, better breakpoint support, less renamed variables).
Reviewed By: mjesun
Differential Revision: D5842305
fbshipit-source-id: d99f719794e4a8f48fd10b0349fbb36f2994666e
Summary:
This copies the basic loading mechanism and default config from the RN local cli into Metro and exposes it under `metro-bundler`, and switches internal scripts over to it.
davidaurelio: I changed the packager-worker-for-buck to hardcode the rn.cli file, like we do in other files. I would like to pull the "find" mechanism that traverses up to find a config into Metro at some point, but for now I'd prefer to keep it lean until we need it. Let me know if that doesn't work for you.
The next diff will switch the RN cli over to these functions also.
Reviewed By: davidaurelio
Differential Revision: D5832596
fbshipit-source-id: a3e167644d96c8831e5a83378e8ba143e62426db
Summary: As a first step in defining a new public API and CLI for Metro, I'd like to pull the generally useful pieces from the RN cli into Metro. This diff makes it as a non-breaking change (so we don't have to bump the version of Metro for RN) by updating only the imports outside of the react-native-github folder.
Reviewed By: davidaurelio
Differential Revision: D5832464
fbshipit-source-id: 11b00b5517665441763c2207d577ae0e110c681b
Summary: Fixed the UNBUNDLE magic file location to match what JniJSModulesUnbundle.cpp expects.
Reviewed By: sahrens
Differential Revision: D5821637
fbshipit-source-id: 4342e4bb4d139b4eba77dd92a53b1683041fc7e9
Summary:
This diff renames all the stragglers in comments and strings from variations of "packager" to "Metro Bundler". I did one of three:
* Rename "packager" to "Metro Bundler"
* Rename "react-native-packager" to "Metro Bundler"
* Remove "packager" when code inside of Metro implies that it's about Metro
I also removed `Glossary.md` because it is unmaintained and very old. mjesun is currently starting to write documentation for Metro which will supersede whatever was there before.
Reviewed By: mjesun
Differential Revision: D5802993
fbshipit-source-id: ba99cb5ed04d84b0f7b7a8a0bf28ed99280a940a
Summary: When starting to use `metro-bundler` as a standalone server, I found quite complicated the fact that it needs a transformer by default. Moreover, the transformer is not passed as a reference to a JS object, but as a path to a required file. I removed the need to be required, and defaulted to a dummy, basic transform, that does nothing by default. This avoids having to create an extra file and linking to it (potentially needing to involve `path` and other extra modules).
Reviewed By: cpojer
Differential Revision: D5622906
fbshipit-source-id: 0c2b1bec86fa542b3c05de42c89d4b5bb4384b34
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? -->
I am sending this PR to fix an error in TransformCaching module. See this issue [TransformCaching module try to collect cache every time I build bundle #46](https://github.com/facebook/metro-bundler/issues/46).
**Test plan**
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->
```
/**
* When restarting packager we want to avoid running the collection over
* again, so we store the last collection time in a file and we check that
* first.
*/
_collectCacheIfOldSync() {
const {_rootPath} = this;
const cacheCollectionFilePath = path.join(_rootPath, 'last_collected');
const lastCollected = Number.parseInt(
tryReadFileSync(cacheCollectionFilePath) || '',
10,
);
if (
Number.isInteger(lastCollected) &&
Date.now() - lastCollected < GARBAGE_COLLECTION_PERIOD
) {
return;
}
const effectiveCacheDirPath = path.join(_rootPath, CACHE_SUB_DIR);
mkdirp.sync(effectiveCacheDirPath);
collectCacheSync(effectiveCacheDirPath);
fs.writeFileSync(cacheCollectionFilePath, Date.now().toString());
}
```
Steps:
1. Create a new react-native project.
2. Put your breakpoint at this sentence `collectCacheSync(effectiveCacheDirPath);`.
3. Bundle the project, program will break at `collectCacheSync(effectiveCacheDirPath);`
4. Resume the program, finish the first time bundle.
5. Bundle again, this time program won't break.
Closes https://github.com/facebook/metro-bundler/pull/48
Differential Revision: D5726161
Pulled By: jeanlauliac
fbshipit-source-id: 0865f1bf25d6eb36f067ac3dc7764df9fd5026dc
Summary:
The HMR logic used to try to calculate the dependencies of every new added (or modified) file, including assets. This resulted in a TransformError.
This commit adds a check that stops the HMR bundling once it finds out that the updated file is an asset
Reviewed By: cpojer
Differential Revision: D5697391
fbshipit-source-id: faf7ccad76ac4922b70ed1c7ce8ce32b03c4e8ee
Summary: We were not using the timeout at all, so we decided to remove it. Also, the current value is pretty high, so it should never fail unless there's something really bad.
Reviewed By: jeanlauliac
Differential Revision: D5640839
fbshipit-source-id: 3eaa567a6828902376fe5df9fe3f4e96b83a23bd
Summary:
We'll revert when the root problem is fixed, that should mitigate for now.
What might be the root problem, I believe, is that when there are some cached files already on the machine, we immediately try to build all the dependencies, but the worker farm is queuing these and it takes a long time to finish. The timeout should include only the transformation time, not the queuing. I'll fix that separately.
Reviewed By: mjesun
Differential Revision: D5650380
fbshipit-source-id: f4b045876cc822caee3998f69ca98ea986709bf4
Summary: It might be that Metro bundler is getting used directly with the `http` module and not within an express app. If that's the case, the `next` method will not exist, so we have to guard against it.
Reviewed By: davidaurelio
Differential Revision: D5639944
fbshipit-source-id: bcee4a70f6a7b643218b11af0d8aedbc7762eead
Summary: This is the last piece of work to make all the clients do a single request for both HMR/non-HMR modes. I'm not completely sure how this URL is used by the client, but it does not need the `hot` param.
Reviewed By: davidaurelio
Differential Revision: D5639946
fbshipit-source-id: a76f9ba7b9ace625352a156761d3ee2809f80c92
Summary:
This diff enables the HMR transforms for any bundle requested through the metro-bundler HTTP server, so it ignores the `hot` parameter passed in the URL.
This allows much faster switches when enabling/disabling HMR, since metro-bundler does not need to re-compile each single file again, while not impacting substantially build times when HMR is off.
I've done some lightweight benchmarks on my machine and these are the results (all the tests have been done after running metro-bundler with a clean cache and restarting the app).
**Before**
Time to build (HMR off): 1x (baseline)
Time to build (HMR on): 1.90x
**This diff**
Time to build (HMR off): 1.009x
Time to build (HMR on): 1.036x
(The reason why now it takes double the time to load the HMR bundle than the non-HMR bundle after launching the app is because the device after a restart always asks for the non-HMR bundle and afterwards the HMR bundle, causing the server to have to build both bundles).
**Bundle size**
In terms of bundle size, adding the HMR transforms increases the size by around 3-4% (this regression is due to the wrappers added around React components, and will depend on the app).
**Next steps**
There are two improvements to do after this diff:
1. Remove the `hot=true` parameter from the clients when they request the bundle. This will reduce by half the memory used by metro-bundler when switching from non-HMR to HMR (or when opening the app with HMR enabled), since metro-bundler caches the bundles based on url.
2. After this diff, the `hot` parameter in the various options objects will not make much sense, so my suggestion is to just remove it from everywhere and instead of checking for that parameter in the transformer, check for `dev=true` there.
Reviewed By: davidaurelio
Differential Revision: D5623623
fbshipit-source-id: cb76b9182e55f442e2987fcf59eee2ba2571578e
Jean Lauliac
Rafael Oleza
Sina Sabet
Lee Byron
Ian Levesque
David Aurelio
Christoph Nakazawa
Alexander Gugel
Kevin Gozali
Miguel Jimenez Esun
Marshall Roch
yeyuanfeng
Ben Nham
Andres Suarez
Alex Dvornikov