Summary:Instead of loading `'babel-polyfill'` into packager, we only polyfill es6 methods that are unavailable in node 4, and es7 stage 4 proposals.
That makes sure that we are using native promises, and don't load unnecessary polyfills.
Reviewed By: vjeux
Differential Revision: D3168057
fb-gh-sync-id: 68b53795d9a1d7cfdc00fc31684da3ad21a7bb34
fbshipit-source-id: 68b53795d9a1d7cfdc00fc31684da3ad21a7bb34
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
David Aurelio
Adam Miskiewicz
Tadeu Zagallo
Martín Bigio