Summary:
We have found that it is useful to work with production rather than dev bundles when working on e.g. performance and animation tuning.
For a larger app, `react-native bundle` with `--dev false` can get very slow due to minification - in our case, this was especially true of library code (e.g. the AWS SDK taking nearly 15 secs to minify on a top-spec MBP 15"). This is fine when just building every now and then, but when making frequent changes and rebuilding, it becomes quite painful.
Currently there is no way to perform a release (non-dev) build, with minification disabled. This PR adds an optional `--minify` flag to enable developers to disable minification, reducing build times significantly for our use case.
Checked output bundle size, to ensure behaviour stays the same as the existing default when `--minify` is not specified, and that the `minify` flag gets passed through to Metro bundler correctly if specified.
N/A
[GENERAL] [ENHANCEMENT] [Bundler] - Added optional --minify flag to bundler
Closes https://github.com/facebook/react-native/pull/17702
Differential Revision: D6806356
Pulled By: shergin
fbshipit-source-id: c466a2dea692561f8b2002118662c3affc71b991
Summary: Tries to adress https://github.com/facebook/metro/issues/65. We need a reasonnable workaround to support modules like `moment.js` that do dynamic requires but only in some cases. By replacing the call by a function that throws, we move the exception at runtime instead of happening at compile time. We don't want to do that for non-node_modules file because they are fixable directly, while `node_modules` are not fixable by people and they get completely blocked by the error at compile time.
Reviewed By: rafeca
Differential Revision: D6736989
fbshipit-source-id: a6e1fd9b56fa83907400884efd8f8594018b7c37
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: Upgrade metro-bundler to v0.9.0. This version has no functional change. The only change is that the structure of the npm package reflects the structure of the source code.
Reviewed By: bestander
Differential Revision: D5315651
fbshipit-source-id: 3a69337106d4ccf708823c80d304941973360e8e
Summary:
This diff cleans up some cruft and adds some features:
* It removes the usage of an env variable to control workers.
* It removes the lazy and handwavy calculation on how many workers to use for jest-haste-map. Jest itself uses the maximum amount of workers available and it has never been reported as an issue – especially since it is a one-time startup cost of about 3 seconds on a cold cache only.
* It adds a `--max-workers` flag to replace the env variable. This one is able to control both the number of workers for `jest-haste-map` as well as the transformers.
* It makes the transformers run in the parent process if 1 or fewer workers are are specified. This should help with debugging.
Once you approve this diff, I will publish a new version of metro to npm and update the version used in RN and remove the use of the env variable altogether: https://our.intern.facebook.com/intern/biggrep/?corpus=xplat&filename=&case=false&view=default&extre=&s=REACT_NATIVE_MAX_WORKERS&engine=apr_strmatch&context=false&filter[uninteresting]=false&filter[intern]=false&filter[test]=false&grep_regex=
Note: the process of adding a CLI option is really broken. Commander also has a weird API. We should consider building a better public API for Metro and then consider how to build a new CLI on top of it and simplify our internal integration. I really don't like how Metro is integrated across pieces of the RN cli in ways that is hard to manage. But that is a larger task for another time :)
Reviewed By: jeanlauliac
Differential Revision: D5217726
fbshipit-source-id: 74efddbb87755a9e744c816fbc62efa21f6a79bf
Summary:
This changeset moves the creation of the transform cache at the top-level of the bundler so that:
* we can use alternative folders, such as the project path itself, that I think will be more robust especially for OSS;
* we can disable the cache completely, that is useful in some cases (for example, the script that fills the global cache).
The reasons I believe a local project path is more robust are:
* there are less likely conflicts between different users and different projects on a single machine;
* the cache is de facto cleaned up if you clone a fresh copy of a project, something I think is desirable;
* some people have been reporting that `tmpDir` just returns nothing;
* finally, it prevents another user from writing malicious transformed code in the cache into the shared temp dir—only people with write access to the project have write access to the cache, that is consistent.
Reviewed By: davidaurelio
Differential Revision: D5113121
fbshipit-source-id: 74392733a0be306a7119516d7905fc43cd8c778e
Summary: `transformModulePath` used to be an optional string, because `ConfigT` allowed for an optional `getTransformModulePath` method. Effectively, we required it to be present. This builds on top of the cleanups around `ConfigT` and gets rid of the flow error suppressions
Reviewed By: jeanlauliac
Differential Revision: D5037466
fbshipit-source-id: bc5c9cbc566e7aa74e7f6397e69fa87cdac7bc00
Summary:
Splits `ConfigT` into `ConfigT` (core + packager configuration) and `RNConfig` (RN CLI configuration).
Also guarantees that all values on `ConfigT` have a default when loading user configuration.
Reviewed By: jeanlauliac
Differential Revision: D4985965
fbshipit-source-id: bf036e22d6809e49746a9c3aa240ec403a085342
Summary:
Similar to https://github.com/facebook/jest/pull/2877, this introduces an optional config `HasteImpl` of type `{getHasteName(filePath: string): (string|void)}` that returns the haste name for a module at filePath if it is a haste module or undefined otherwise.
This allows us to inject a custom implementation of haste's module id resolution rather than only relying on `providesModule` annotations
Reviewed By: davidaurelio
Differential Revision: D4589372
fbshipit-source-id: 4d1983dfbf09c9d67faf725e86ae86ab42433b7d
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
Summary:
This is step one on merging the `rnpm` config with the `cli config`. The plan is to remove two sources of truth (rnpm package.json config and rn-cli Javascript config)
Rationale:
As of now, we have `rnpm` config, that used to live in the `local-cli/core/config/index.js` and the `rn-cli` config, living in `default.config.js` and `utils/Config.js`.
This PR moves all the things into one file, called `local-cli/core', simplifies things, enhances types (Config now has better types, added missing properties and fixed descriptions).
One notable addition is that users can now opt-in to override the commands that are loaded at the package level. Previously it was only possible to add a command by writing a plugin. Now, you can just tweak the `rn-cli.config.js`.
This is one of the several improvements I have on my roadmap, with better documentation for the CLI as well.
Closes https://github.com/facebook/react-native/pull/11564
Differential Revision: D4360095
fbshipit-source-id: feaec7c88df63e51cef1f9620c7eedeb738d3d00
Summary:
Instead of exposing a `getTransformOptionsModulePath` function in configurations, we can simply expose a `getTransformOptions` *function*. The necessity of exposing a path comes from the olden days, where we had a server listening on a socket, and a client, talking to that server.
Since that architectural gem no longer exists, we can use functions directly, rather than passing paths to modules around.
Reviewed By: cpojer
Differential Revision: D4233551
fbshipit-source-id: ec1acef8e6495a2f1fd0911a5613c144e8ffd7c3
Summary:
This removes support for `require('image!…')`, which has been deprecated for a long time.
It is still possible to use images that are already bundled by the native app using the `nativeImageSource` module.
Check http://facebook.github.io/react-native/docs/images.html for detailed documentation.
Reviewed By: matryoshcow
Differential Revision: D4231208
fbshipit-source-id: 05ec4c1ca0fabdc3fbb652f8ad1acdf240a67955
Summary: Adds flow types for output functionality for easier maintenance and interop with new code
Reviewed By: matryoshcow
Differential Revision: D4211863
fbshipit-source-id: 591407d3a6d49536054ae94ba31125c18a1e1fa1
Summary: Switch to native promises in the local cli
Reviewed By: davidaurelio
Differential Revision: D4213142
fbshipit-source-id: aff99f8bb3dc237cecc852cdb09dee9b49b05753
Summary:
This is the next incremental step to rewrite node-haste. I apologize for the size of this diff but there is really no smaller way to do this. The current architecture passes a single file watcher instance into many classes that each subscribe to file changes. It's really hard to keep track of this. The new implementation reduces the listeners to two (will eventually be just one!) - one in DependencyGraph and one in it's parent's parent's parent (ugh! This doesn't make any sense). This should make it much more straightforward to understand what happens when a file changes.
I was able to remove a bunch of tests because jest's watcher takes care of things like ignore patterns. Some of the tests were specifically testing for whether the change events were invoked and they are now much more straightforward as well by manually invoking the `processFileChange` methods.
(Relanding a fixed version of D4161662)
Reviewed By: kentaromiura
Differential Revision: D4194378
fbshipit-source-id: 8c008247a911573f6b5f6b0b374d50d38f62a4f5