Summary: We are already inlining `Platform.OS`. This diff adds support to inline calls to `Platform.select` with an object literal as first argument. The transform will replace the call with the property value corresponding to the platform, or `undefined` if it does not exist.
Reviewed By: frantic
Differential Revision: D3385391
fbshipit-source-id: bb068d17948ed84e381707faeaa0450399c2f306
Summary: We also need a more recent version of uglify that supports this
Reviewed By: martinbigio
Differential Revision: D3024959
fb-gh-sync-id: f9efdddceda4f726567c39884c844a8e74e6e09d
shipit-source-id: f9efdddceda4f726567c39884c844a8e74e6e09d
Summary:Make packager transform files before extracting their dependencies.
This allows us to extract dependencies added by transforms (and to avoid including them manually).
It also allows for better optimization and to get rid of the “whole program optimization” step:
This diff utilizes the new worker introduced in D2976677 / d94a567 – that means that minified builds inline the following variables:
- `__DEV__` → `false`
- `process.env.NODE_ENV` → `'production'`
- `Platform.OS` / `React.Platform.OS` → `'android'` / `'ios'`
and eliminates branches of conditionals with constant conditions. Dependency extraction happens only after that step, which means that production bundles don’t include any modules that are not used.
Fixes#4185
Reviewed By: martinbigio
Differential Revision: D2977169
fb-gh-sync-id: e6ce8dd29d1b49aec49b309201141f5b2709da1d
shipit-source-id: e6ce8dd29d1b49aec49b309201141f5b2709da1d
Summary:This limits the number of spawned transformation workers depending on the number of available cores (`n`):
```
n < 3 → n
n < 8 → floor(3/4 * n)
n < 24 → floor(3/8 * n + 3) // factor going from 3/4 to 1/2
n >= 24 → floor(n / 2)
```
Reviewed By: bestander
Differential Revision: D2999894
fb-gh-sync-id: 0163240b5f066432f9ba07161c0dfa2ec767ba58
shipit-source-id: 0163240b5f066432f9ba07161c0dfa2ec767ba58
Summary:This adds a new worker implementation that
- uses the existing transforms to transform code
- optionally inline `__DEV__`, `process.env.NODE_ENV`, and `Platform.OS`
- optionally eliminate branches of conditionals with constant conditions
- extracts dependencies
- optionally minifies
This will land as part of a multi-commit stack, not in isolation
Reviewed By: martinbigio
Differential Revision: D2976677
fb-gh-sync-id: 38e317f90b6948b28ef2e3fe8b66fc0b9c75aa38
shipit-source-id: 38e317f90b6948b28ef2e3fe8b66fc0b9c75aa38
Summary: This updates to the latest published node-haste version, and also adapts code and tests to that version. Future upgrades should be easier.
Reviewed By: bestander
Differential Revision: D2963144
fb-gh-sync-id: 9fd2c84fc49643fb85ee5d9674a5e458d43d44ca
shipit-source-id: 9fd2c84fc49643fb85ee5d9674a5e458d43d44ca
Summary: This installs the 2.0 version of node-haste, removes the DependencyResolver and fixes up all the tests.
Reviewed By: davidaurelio
Differential Revision: D2943416
fb-gh-sync-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
shipit-source-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
Summary:
Rather than specifying Babel plugins in the `.babelrc` packaged with react-native, leverage a Babel preset to define the plugins (https://github.com/exponentjs/babel-preset-react-native).
This allows for a much better user experience for those who want (or need) to override options in their project's `.babelrc`.
Prior to this PR, if a user wanted to use a custom babel-plugin (or a custom set of babel plugins), they'd have either 1) manually override the `.babelrc` in the react-packager directory (or fork RN), or 2) specify a custom transformer to use when running the packager that loaded their own `.babelrc`. Note - the custom transformer was necessary because without it, RN's `.babelrc` options would supersede the options defined in the project's `.babelrc`...potentially causing issues with plugin ordering.
This PR makes the transformer check for the existence of a project-level `.babelrc`, and if it it's there, it _doesn't_ use the react-native `.babelrc`. This prevents any oddities with Babel plug
Closes https://github.com/facebook/react-native/pull/5214
Reviewed By: davidaurelio
Differential Revision: D2881814
Pulled By: martinbigio
fb-gh-sync-id: 4168144b7a365fae62bbeed094d8a03a48b4798c
Summary:
public
`babel-plugin-react-transform` doesn't support to run on transformed code (it doesn't detect some react components). The reason why HMR was originally on the internal transform was so that it worked with non JS code (TypeScript, Coffeescript, etc), but looks like this is not very popupar in the community, maybe because the JS ecosystem is getting better everyday.
So long story short, for now lets move HMR to the external transformer. This should also give us a perf boost.
Reviewed By: davidaurelio
Differential Revision: D2870973
fb-gh-sync-id: 68ca8d0540b88b9516b9fef10643f93fc9b530d2
Summary:
public
We had a bug a few weeks ago which caused transform errors not to be shown properly. The problem was on this piece of code, so lets unit test it.
Reviewed By: davidaurelio
Differential Revision: D2849990
fb-gh-sync-id: 9f6bb8a8b7d59bbaa3577c29cee37fb23a50d66f
Summary:
public
- Tweak OSS server to enable the HMR connection
- Remove client gating code.
- Resolve internal transforms plugins
After this diff, Hot Loading should work on OSS.
Reviewed By: javache
Differential Revision: D2803620
fb-gh-sync-id: b678180c884d2bfaf454edf9e7abe6b3b3b32ebe
Summary:
One consequence we didn't predict after introducing the Internal Transform Pipeline, was that when the workers would get started, we won't require the external transformer the user specified up until the first time each worker received a job. There're 2 visible consequences of this: (1) the transform progress bar seems to get stuck for about 5 seconds the first time the packager receives a request and (2) the first N (# of cores) HMR requests take way longer (about 4 seconds with FB's transformer instead of << 1 second) as we need to require lots of modules.
This diff creates a temporary file for the js transformer workers that requires the user-specified transform file eagerly.
That makes sure workers have imported babel and the transforms before receiving the first request.
There are better ways to do this, like adding an `init()` method to the workers and call that eagerly. I will follow with another diff doing that.
public
Reviewed By: javache
Differential Revision: D2812153
fb-gh-sync-id: 15be316b792d1acd878ed9303bea398aa0b52e1d
Summary:
public
We want to support Hot Loading on the packager itself instead of on the transformer. This will allow us to enable it on OSS (and for any scripting language, yay!).
For now to enable Hot Loading the packager's internals transforms need to be manually enabled (start packager with `--enable-internal-transforms`). I think the internal pipeline should always be enabled as it doesn't affect performance if there're no transforms and the user can disable Hot Loading through the setting on the app though. I'll tweak this on a follow up commit.
Reviewed By: vjeux
Differential Revision: D2801343
fb-gh-sync-id: 563984d77b10c3925fda6fd5616b814cdbea2c66
Summary:
public
Fixes an issue on the transforms pipeline which caused not to pipe errors that occured on the external transformer to JSTransformer.
Reviewed By: yungsters
Differential Revision: D2806498
fb-gh-sync-id: c9347d1957a3a9320b3f177ff9b19bf3802087a0
Summary:
public
This diff introduces an internal transforms pipeline that integrates with the external one. This has been a feature we've been looking to implement for a long time to use babel instead of `replace` with regexps on many parts of the packager.
Also, to split the bundle we'll need to run one transform. Internally for Facebook we can run the system-import transform altogether withe the other ones. For OSS we offer `transformer.js` which people can use out of the box if they're writing ES6 code. For those people, `transformer.js` will also run the internal transforms`. However they might want to tune the transforms, or even write the code on another language that compiles to Javascript and use a complete different transformer. On those cases we'll need to run the external transforms first and pipe the output through the internal transforms. Note that the order it's important as the internal transforms assume the code is written in JS, though the original code could be on other scripting languages (CoffeeScript, TypeScript, etc).
Reviewed By: davidaurelio
Differential Revision: D2725109
fb-gh-sync-id: d764e209c78743419c4cb97068495c771372ab90
Summary:
Currently, the app server accepts `transformModulePath` which allows us to use different transformation variants. However, these options persist through the lifetime of the server. So we cannot conditionally transform a module differently for two bundles without restarting the server with different options.
`getTransformOptions` basically allows us to change the options to the transformer at runtime based on the bundle and module being transformed.
These options are also used as a cache key for the transformedSource to ensure that if a file is transformed with different options, caching doesn't cause any inconsistencies.
public
Reviewed By: martinbigio
Differential Revision: D2776399
fb-gh-sync-id: 1e0f34d8fa7f0377fcf81f23eb6f3236bd397d56
Summary: @public
Have a top-level debug namespace: `ReactNativePackager`
And add a couple of debugs in the transformer. This is ground work for adding a verbose option.
Reviewed By: @DmitrySoshnikov
Differential Revision: D2489960
Summary:
Fix error in the template string (no plus, thinks it's a function).
And bump the timeout to 30 seconds because a file is taking more than 10 seconds `js/RKJSModules/Libraries/FBComponents/FBFed/FeedStoryFragments.js`
Summary:
There's been a case where Babel can hang indefinitely on a file parse/transform. Possibly related to https://github.com/babel/babel/issues/2211
This adds a timeout to transform jobs and throws an error informing the user of the offending file. The timeout interval defaults to 10 seconds, but can be changed via an option.
Summary:
The cache is only used for JSTransformer at the moment. We're doing IO and some computation to get each module's name, whether is a haste or node module and it's dependencies. This work happens on startup so by caching this value we shouldbe able to reduce the start up time. Lets promote the Cache to the Packager level to be able to use it by any of the components of the packager. For now, on this diff we'll start using it to cache the mentioned fields.
Also we had to introduce the concept of fields in the cache as manually merging the date we had for each path is not possible as we're using promisses all around. With the new API, each field is a promise.
@amasad and I did some manual testing to measure the impact of this change and looks like it's saves 1 second when building the haste map (which represents 50% of the time). Overall this reduces 1 second of start up time which was currently about 8s on my mac book pro.
Summary:
[This is a preview diff for getting RN's tests to pass with a future version of jest that supports io.js and other future versions of Node. This can be merged once the diff to update jest is merged upstream and published.]
Updates the tests in small ways so they run on io.js with two updates:
- The Cache test which relies on Promises uses `runAllImmediates` for modern versions of Node because bluebird uses `setImmediate` instead of `process.nextTick` for Node >0.10.
Closes https://github.com/facebook/react-native/pull/1382
Github Author: James Ide <ide@jameside.com>
Test Plan: Run `npm test` with the latest version of jest.
Summary:
@public
Previously, we had to use errors as a property on the result object because there was no way to pass custom props between
the child worker and the parent. This has been fixed in node-worker-farm (D2092153) and now we can use regular errors.
This also adapts the transformer to babel-specific errors. Generic errors, however, should still work and render readable
info.
Additionally, I deprecated, but maintained backwards compatiblity for people in OSS that are using custom transformers.
Test Plan:
1. `./runJestTests.sh`
2. `./runJestTests.sh PackagerIntegration`
3. open the playground app
4. Add a syntax error. Say `1=x` somewhere in the file
5. Reload and see error message 'SyntaxError <filename> description (line:col)'
6. Make sure that the stack trace is clickable and it attempts to open the editor to the location
Summary:
@public
Shouldn't confuse the cache from files transformed by different transformers. This takes into account the transformer in the cache hash name.
Test Plan:
* start server with --babel
* generate bundle
* start server with --jstransform
* generate bundle
* compare them and they're different
Summary:
@public
Fixes [#393](https://github.com/facebook/react-native/issues/393). Currently the transformer assumes line-preserving compilers and defaults to a super-fast source map generation process. However, we need to support compilers that aren't preserving lines.
I had feared this wuold slow down the server but I came about a little known peace of the spec that defines an "indexed source map" just for the purpose of concating files: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
Test Plan:
1. runJestTests.sh
2. run server and click around example apps
3. add a custom transporter like babel
4. add a custom file and a debugger statement
5. debug in chrome and make sure it works
redbox still works
David Aurelio
Christoph Pojer
Mike Grabowski
Kureev Alexey
Adam Miskiewicz
Martín Bigio
Bhuwan Khattar
Amjad Masad
Pieter De Baets
Alex Kotliarskyi
Thomas Aylott
James Ide
Forbes Lindesay
Dmitry Soshnikov
Pilwon Huh
Christopher Chedeau
