Commit Graph

7 Commits

Author SHA1 Message Date
Janic Duplessis fd40670869 Use a separate babel config for the local-cli and the packager
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.

I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.

**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.

I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155

Reviewed By: bestander

Differential Revision: D3301008

Pulled By: davidaurelio

fbshipit-source-id: 504180d158a1e50bc03e28fb0d1e53d0731ce32f
2016-05-21 06:58:26 -07:00
Janic Duplessis b6d447769b Reverted commit D3242754
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.

I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.

**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.

I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155

Differential Revision: D3242754

Pulled By: eczarny

fb-gh-sync-id: 6cd349e284b7d92a1b2cc8b5c0e26adbfb0d9a2f
fbshipit-source-id: 6cd349e284b7d92a1b2cc8b5c0e26adbfb0d9a2f
2016-04-30 16:54:31 -07:00
Janic Duplessis 50145b659f Use a separate babel config for the local-cli and the packager
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.

I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.

**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.

I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155

Differential Revision: D3242754

Pulled By: davidaurelio

fb-gh-sync-id: 02880c841c10562d5f107e1c975d668e55cc619f
fbshipit-source-id: 02880c841c10562d5f107e1c975d668e55cc619f
2016-04-30 16:25:24 -07:00
David Aurelio c16cfc694b Don't load 'babel-polyfill', only polyfill `Array#values`, `Object.values`, and `Object.entries`
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
2016-04-12 08:29:20 -07:00
Adam Miskiewicz 38cea2edeb Use "babel-preset-react-native"
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
2016-02-03 08:15:32 -08:00
Tadeu Zagallo a88f69e482 Upgrade transformers to be compatible babel 6
Reviewed By: vjeux

Differential Revision: D2626155

fb-gh-sync-id: e919c8fb8bbf139bcd979ee2738c7ec4fc9eba74
2015-11-10 10:55:23 -08:00
Martín Bigio fc7d01e2ab fix E2E tests
Reviewed By: @mkonicek

Differential Revision: D2526310

fb-gh-sync-id: 1c04f56073dc5b393a36b258c039fdfd85ab83a2
2015-10-09 07:59:02 -07:00