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
Summary: now that `ResolutionRequest.resolveDependency` is synchronous, we can also make `ResolveFn` synchronous.
Reviewed By: fkgozali
Differential Revision: D5528094
fbshipit-source-id: 0b40df29024b809a99b7e577716b24e9fa499578
Summary: Adds filtering to the assets written from a Buck build, so that we don’t write all assets present in libs, but rather only the ones included in the bundle.
Reviewed By: cpojer
Differential Revision: D5522844
fbshipit-source-id: fcca3567b726dfab1ecf9560932fd6e1a174b31f
Summary: makes flow typing for the entry point more sound and fixes two issues
Reviewed By: BYK
Differential Revision: D5507650
fbshipit-source-id: 6b03f7de792ffcece4d0d61950e136a61ea7db2e
Summary: Format everything, one subdir at a time.
Reviewed By: mjesun
Differential Revision: D5481590
fbshipit-source-id: 6d9157e6857d61b8116bcf9285bd4be415c5ba01
Summary:
By default, when Babel transforms a file, it looks for .babelrc in the file's directory and all parent directories until it finds a .babelrc file. This means that when Metro tries to transform `<PROJECT_ROOT>/node_modules/dep/mod.js`, it searches for `<PROJECT_ROOT>/node_modules/dep/.babelrc`. If that .babelrc actually exists, Babel will try to apply it.
In practice, this often causes problems because packages that include .babelrc often do so unintentionally -- they don't intend for the package consumer to look at that .babelrc file. One thing we've done a lot is `rm` all .babelrc files under node_modules -- this commit effectively achieves the same in a less destructive way by telling Babel not to look up .babelrc files. (To clarify, Metro will still apply the .babelrc file in the project root.)
Since the current behavior is to look at .babelrc files, this commit keeps that behavior for now. We'll consider overriding the default behavior (that is, making Babel not lookup .babelrc files) in the default configuration of Expo/RN projects. If this goes well and we empirically find that people are having a better time, we may want to consider flipping this option's default in Metro, so that Metro tells Babel not to look up .babelrc files by default.
Closes https://github.com/facebook/metro-bundler/pull/31
Differential Revision: D5469620
Pulled By: jeanlauliac
fbshipit-source-id: fe7a1042feafff843e1a6d8cc9487eb6ff8e8358
Summary:
The main goal of this is to be able to show bundle download progress in a follow up PR for react-native.
**Test plan**
Tested that it is possible to show bundle download progress in react-native using this header and added unit test.
Closes https://github.com/facebook/metro-bundler/pull/28
Reviewed By: davidaurelio
Differential Revision: D5443344
Pulled By: jeanlauliac
fbshipit-source-id: 63fd655c964d7df526125fbe55eb9c7cccd7dba9
Summary:
Adding a Babel plugin that will analyze the file looking for any potential candidate to use `regenerator-runtime`, and if so, will inject dynamically the module. The module is injected per file, so we avoid polluting the global environment. The plugin is also able to inject the `require` call beforehand, so that the inliner can pick them and inline them.
The Babel plugin is part of `react-native-babel-preset`, so as long as you are using this preset you are safe. If not, you should include the specific transformer into your list of plugins, as `react-native-babel-preset/transforms/transform-regenerator-runtime-insertion.js`.
Reviewed By: davidaurelio
Differential Revision: D5388655
fbshipit-source-id: dc403f3d5e2d807529eb8569a85c45fec36a6a3e
Summary:
I corrupted the yarn.lock when trying to downgrade that module. This change brings the correct resolution in the `yarn.lock`.
Closes https://github.com/facebook/metro-bundler/pull/29
Differential Revision: D5452305
Pulled By: jeanlauliac
fbshipit-source-id: 54026cfd9cf269e2b432dd92f16bd6db9fa4603c
Summary: Downgrade the locked version of Babel block scoping, kinda temporarily until we upgrade internally. This makes in on par with the version we use internally, so that the `basic_bundle` test had the same results on both infrastructures. This doesn't change a single thing for `metro-bundler` consumers, because this `yarn.lock` file is only used for testing/CI, not when the library is installed as part of a project.
Reviewed By: cpojer
Differential Revision: D5442368
fbshipit-source-id: f3033e450855f7d61ac775a46719d7b1743960c5
Summary: Now we have a nice specific error type for duplicates errors. This changeset have been commited before but was reverted as part of a stack, so here we go again.
Reviewed By: cpojer
Differential Revision: D5442363
fbshipit-source-id: 068c8decaf20cd4f9a73d9d54984030c79cff606
Summary: I appears `Object.assign` is not properly typed-checked by Flow, and silently so, so I propose we switch to an explicit list until we find an alternative solution. I prefer to have strong typing especially for options, and as the lack of typing has caused breakage before.
Reviewed By: cpojer
Differential Revision: D5442319
fbshipit-source-id: 82b0ec760c7dea6da6f7932896243147ce12ebf9
Summary: I'd like to get rid of the function as blacklist, because it's impossible to process properly at the `jest-haste-map` level (https://github.com/facebook/jest/pull/4047). The reason we use a function in Metro bundler is because we excludes all the `__tests__` modules. However, I removed this exclusion completely, and I could build our package without any problem and with no difference in the final bundle. I can only assume, then, that this line is only here for slightly increasing performance. Therefore, I think it's reasonnable to move it as part of the default blacklist shipped with Metro bundler instead.
Reviewed By: cpojer
Differential Revision: D5434351
fbshipit-source-id: dea39f6299985143d25fcb3b7b365d793acd64a9
Summary: Now we have a nice specific error type for duplicates errors.
Reviewed By: cpojer
Differential Revision: D5433438
fbshipit-source-id: 47cad9ca6bf0bdec91a158ccb2807b6c5571966a
Summary: This put it on par with the version we use on other projects. This new version breaks assumptions about the way Promise/ticks/timers use to work, and I was not able to make it work properly synchronously. Since it's fragile anyway (because rely on Promise and feature internals), I propose the switch to async as done in this changeset. If `res.end` is not called, tests will just timeout instead.
Reviewed By: cpojer
Differential Revision: D5423823
fbshipit-source-id: 015e808a2cf2b8297a36b16feeb811a6e745a835
Summary: Going one step further, we can start working around the throwing version. To simply some code, I also piggybacked the addition of helper functions `resolvedAs` and `failedFor` in this changeset, hope it's okay. I can split if necessary.
Reviewed By: davidaurelio
Differential Revision: D5415196
fbshipit-source-id: 1bd5955b5733866af52fa873bcd1d9e4ce8215cf
Rafael Oleza
Jean Lauliac
Miguel Jimenez Esun
David Aurelio
Brian Vaughn
Dmitry Zakharov
Christoph Nakazawa
James Ide
Janic Duplessis
Mehdi Mulani