Use "babel-preset-react-native" #5214

skevy · 2016-01-09T05:24:03Z

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 plugin ordering, and leaves that up to the RN user. The RN user would then just include a .babelrc file in their project that looks like:

{
  "presets": ["react-native"]
}

They can then add whatever other presets or plugins that they'd like (such as the Babel Relay Plugin or a decorators plugin, for example).

Super important note: after the fbjs changes are merged...this is really the final piece of getting Relay running OOTB in RN

/cc @ide @vjeux

facebook-github-bot · 2016-01-09T05:24:33Z

By analyzing the blame information on this pull request, we identified @tadeuzagallo, @davidaurelio and @kittens to be potential reviewers.

facebook-github-bot · 2016-01-09T05:26:11Z

@skevy updated the pull request.

skevy · 2016-01-09T05:30:27Z

@ide @vjeux Should we move babel-preset-react-native under the auspices of the "facebook" or "reactjs" orgs?

skevy · 2016-01-09T05:44:59Z

@martinbigio and/or @davidaurelio...vjeux suggested that one of you guys review :)

satya164 · 2016-01-09T12:07:06Z

Awesome!

vjeux · 2016-01-09T17:11:01Z

Can you make a folder inside of this repo like we do for react-native-cli? Would be easier to manage

skevy · 2016-01-09T18:41:16Z

@vjeux that seems reasonable to me. Should it be committed through the shipit bot? Or should it live in OSS only?

satya164 · 2016-01-10T18:45:48Z

Any reason for the rename of '.babelrc'?

davidaurelio · 2016-01-10T22:37:47Z

Guys, let me discuss this with @martinbigio, we need to sort out one thing ;-)

ide · 2016-01-10T23:04:24Z

@skevy @vjeux: About moving the preset under a folder, sounds good. I'm also happy to add whoever needs to be a collaborator to the repo & npm owners list. I think we can figure that out later.

The main thing I think is important is that the babelrc.json file depends on the preset so that RN's internal configuration stays in sync with people's custom .babelrc files that are using the preset. Also the preset should follow semver, just like any other npm package.

skevy · 2016-01-11T00:09:39Z

@satya164 when @ide and I were talking, we were just thinking that since the RN babelrc is handled custom anyway, via transformer.js, that it should be named with ".json" so there's not a possibility of conflict with any other babelrc's.

ide · 2016-01-14T21:25:08Z

packager/transformer.js


-function transform(src, filename, options) {
-  options = options || {};
+const projectBabelRCPath = path.resolve(__dirname, '..', '..', '..', '.babelrc');


Thinking about this some more, I think the babelrc under the path specified by --projectRoots is what we want to use. That way if you invoke the packager and point it at another directory, we'd correctly use that directory's .babelrc.

I thought about that -- but what are your thoughts on if there are multiple project roots?

This line only works for OS and if react native is in ${projectDirectory}/node_modules/react-native. I’m a little bit afraid of the apocalyptic potential of this innocent path lookup ;-)

Is anybody outside of Facebook using multiple project roots? The first project root might be a saner choice. Or we can add a command line option.

Let's default to the first project root, and I'll add a command line option to specify a babelrc path.

satya164 · 2016-01-15T02:33:22Z

@skevy Just to note, I presume some people have a .babelrc like this (I do),

{
  "extends": "react-native/packager/react-packager/.babelrc"
}

Which will break after the rename. Not a big deal, just wanted to note.

ide · 2016-01-15T02:56:51Z

@satya164 Good point. We should mention it under Breaking Changes in the release notes.

satya164 · 2016-01-15T03:19:08Z

@ide Yup.

davidaurelio · 2016-01-15T10:57:52Z

packager/babelRegisterOnly.js

@@ -16,7 +16,7 @@ var path = require('path');
 var _only = [];

 function readBabelRC() {
-  var rcpath = path.join(__dirname, 'react-packager', '.babelrc');
+  var rcpath = path.join(__dirname, 'react-packager', '.babelrc.json');


Let’s remove the leading dot.

Summary: At the moment we have to disable strict mode for the transform-es2015-modules-commonjs because strict mode leaks to the global scope and breaks the bridge. It was due to the way the polyfills were bundled in the package. To fix it, I wrapped the polyfill modules in an IIFE. Then when strict mode was enabled some polyfills were broken due to strict mode errors so that was fixed too. Also removed the IIFE from the polyfills that included one. This diff doesn't enable the strict mode transform since some internal facebook modules depend on it not being enabled. When #5214 lands we could make the default babel config shipped with OSS react-native use strict mode modules and facebook could just modify the babel config to disable it if needed. This will allow removing `"strict": false` from https://github.com/facebook/react-native/blob/master/packager/react-packager/.babelrc#L16 Fixes #5316 Closes #5422 Reviewed By: svcscm Differential Revision: D2846422 Pulled By: davidaurelio fb-gh-sync-id: a3e2f8909aa87dabab2b872c61b887e80220fb56

Summary: At the moment we have to disable strict mode for the transform-es2015-modules-commonjs because strict mode leaks to the global scope and breaks the bridge. It was due to the way the polyfills were bundled in the package. To fix it, I wrapped the polyfill modules in an IIFE. Then when strict mode was enabled some polyfills were broken due to strict mode errors so that was fixed too. Also removed the IIFE from the polyfills that included one. This diff doesn't enable the strict mode transform since some internal facebook modules depend on it not being enabled. When facebook#5214 lands we could make the default babel config shipped with OSS react-native use strict mode modules and facebook could just modify the babel config to disable it if needed. This will allow removing `"strict": false` from https://github.com/facebook/react-native/blob/master/packager/react-packager/.babelrc#L16 Fixes facebook#5316 Closes facebook#5422 Reviewed By: svcscm Differential Revision: D2846422 Pulled By: davidaurelio fb-gh-sync-id: a3e2f8909aa87dabab2b872c61b887e80220fb56

alvinthen · 2016-01-23T07:58:17Z

packager/transformer.js

-  });
-
-  const result = babel.transform(src, Object.assign({}, babelRC, config));
+  return Object.assign({}, babelRC, extraConfig);


Shouldn't extraConfig be config instead? config doesn't seems to be used anywhere.

facebook-github-bot · 2016-01-25T05:00:19Z

@skevy updated the pull request.

facebook-github-bot · 2016-01-25T05:01:17Z

@skevy updated the pull request.

…itializeJavaScriptAppEngine

…en using the default Babel config

facebook-github-bot · 2016-02-02T17:10:25Z

@skevy updated the pull request.

…'t complain about conflict

facebook-github-bot · 2016-02-02T17:20:25Z

@skevy updated the pull request.

facebook-github-bot · 2016-02-02T17:40:12Z

@skevy updated the pull request.

facebook-github-bot · 2016-02-02T18:07:18Z

@skevy updated the pull request.

facebook-github-bot · 2016-02-02T18:08:13Z

@skevy updated the pull request.

chirag04 · 2016-02-03T20:39:06Z

👍

vjeux · 2016-02-04T21:50:08Z

This officially broke react-native for node < 4.0. We should either revert the arrow functions or crash earlier if not using node 4

skevy · 2016-02-04T21:56:59Z

@vjeux I definitely think we should crash earlier if not using Node 4. No one should be using less than Node 4, and it already says at the top of your screenshot that React Native runs on Node 4.0 or newer.

skevy · 2016-02-04T21:59:08Z

@vjeux can we use https://github.com/facebook/fbjs/blob/master/scripts/node/check-dev-engines.js

vjeux · 2016-02-04T21:59:33Z

We already have https://github.com/facebook/react-native/blob/master/local-cli/server/checkNodeVersion.js

skevy · 2016-02-04T22:00:22Z

@vjeux ah so i guess just exit there if less than node 4.

vjeux · 2016-02-04T22:00:32Z

Cool, i'll send a pull request

bestander · 2016-02-05T00:43:35Z

Be careful with version checks though.
Remember good old browser sniffing or why there is now Windows 9?

On Thursday, 4 February 2016, Adam Miskiewicz notifications@github.com
wrote:

@vjeux https://github.com/vjeux ah so i guess just exit there if less
than node 4.

—
Reply to this email directly or view it on GitHub
#5214 (comment)
.

lrettig · 2016-02-11T16:43:39Z

Is there an ETA on this? Thanks!

skevy · 2016-02-11T17:00:54Z

@lrettig this is already merged in master. It should be in the current RC and will be officially released in 0.20.

lrettig · 2016-02-11T18:14:27Z

Thanks. Didn't see it mentioned in the release notes!

On Thu, Feb 11, 2016 at 12:02 PM, Adam Miskiewicz notifications@github.com
wrote:

@lrettig https://github.com/lrettig this is already merged in master.
It should be in the current RC and will be officially released in 0.20.

—
Reply to this email directly or view it on GitHub
#5214 (comment)
.

facebook-github-bot · 2016-02-11T19:16:36Z

@skevy updated the pull request.

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 facebook#5214 Reviewed By: davidaurelio Differential Revision: D2881814 Pulled By: martinbigio fb-gh-sync-id: 4168144b7a365fae62bbeed094d8a03a48b4798c

Summary:Since #5422 react-native works with strict mode modules but the transform was not updated since Facebook has some non strict mode compatible internal modules. Now that #5214 has landed and it is easy to change the babel config I think we should enable it by default to make es2015 modules spec compliant. Someone at Facebook will have to make the internal changes necessary to disable strict mode modules for their projects that use non strict mode compatible modules by including a .babelrc file with ``` json { "presets": [ "react-native" ], "plugins": [ ["transform-es2015-modules-commonjs", { "strict": false, "allowTopLevelThis": true }] ] } ``` before merging this. We might also want to mention this in the breaking change section for the next release. Closes #5796 Differential Revision: D3075802 fb-gh-sync-id: e807b67401107e1e944db38453e254025ce0a6c7 shipit-source-id: e807b67401107e1e944db38453e254025ce0a6c7

Summary:Since facebook#5422 react-native works with strict mode modules but the transform was not updated since Facebook has some non strict mode compatible internal modules. Now that facebook#5214 has landed and it is easy to change the babel config I think we should enable it by default to make es2015 modules spec compliant. Someone at Facebook will have to make the internal changes necessary to disable strict mode modules for their projects that use non strict mode compatible modules by including a .babelrc file with ``` json { "presets": [ "react-native" ], "plugins": [ ["transform-es2015-modules-commonjs", { "strict": false, "allowTopLevelThis": true }] ] } ``` before merging this. We might also want to mention this in the breaking change section for the next release. Closes facebook#5796 Differential Revision: D3075802 fb-gh-sync-id: e807b67401107e1e944db38453e254025ce0a6c7 shipit-source-id: e807b67401107e1e944db38453e254025ce0a6c7

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 facebook/react-native#5214 Reviewed By: davidaurelio Differential Revision: D2881814 Pulled By: martinbigio fb-gh-sync-id: 4168144b7a365fae62bbeed094d8a03a48b4798c

facebook-github-bot added GH Review: review-needed CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. labels Jan 9, 2016

skevy force-pushed the babel-preset-react-native branch from e008d2d to 151c85e Compare January 9, 2016 05:25

skevy mentioned this pull request Jan 9, 2016

Updating babel to latest version #5097

Closed

skevy force-pushed the babel-preset-react-native branch 2 times, most recently from 2aedde7 to ed0b665 Compare January 9, 2016 05:41

satya164 mentioned this pull request Jan 10, 2016

Update link to babel transforms #5226

Closed

ide reviewed Jan 14, 2016
View reviewed changes

davidaurelio reviewed Jan 15, 2016
View reviewed changes

janicduplessis mentioned this pull request Jan 20, 2016

Make the packager work with babel strict mode transform #5422

Closed

alvinthen reviewed Jan 23, 2016
View reviewed changes

skevy force-pushed the babel-preset-react-native branch from ed0b665 to c5dd703 Compare January 25, 2016 04:58

skevy added 2 commits February 2, 2016 11:50

adding react-transform-hmr back to deps, because it is required in In…

ac526aa

…itializeJavaScriptAppEngine

resolving presets and plugins relative to the react-native package wh…

6dc9574

…en using the default Babel config

remove react-transform-hmr from providesModuleNodeMoudles so it doesn…

d51ea5f

…'t complain about conflict

exporting plugins for use by FB internal transform

e5e3ba7

skevy force-pushed the babel-preset-react-native branch from a439c19 to e5e3ba7 Compare February 2, 2016 17:38

add react-transform babel plugin to plugin exports

a02a8d1

bumping babel-preset version

658ef22

ghost closed this in e6cb02d Feb 3, 2016

janicduplessis mentioned this pull request Feb 7, 2016

Enable strict mode for transform-es2015-modules-commonjs #5796

Closed

This pull request was closed.

Use "babel-preset-react-native" #5214

Use "babel-preset-react-native" #5214

Conversation

skevy commented Jan 9, 2016

facebook-github-bot commented Jan 9, 2016

facebook-github-bot commented Jan 9, 2016

skevy commented Jan 9, 2016

skevy commented Jan 9, 2016

satya164 commented Jan 9, 2016

vjeux commented Jan 9, 2016

skevy commented Jan 9, 2016

satya164 commented Jan 10, 2016

davidaurelio commented Jan 10, 2016

ide commented Jan 10, 2016

skevy commented Jan 11, 2016

ide Jan 14, 2016

Choose a reason for hiding this comment

skevy Jan 15, 2016

Choose a reason for hiding this comment

davidaurelio Jan 15, 2016

Choose a reason for hiding this comment

skevy Jan 25, 2016

Choose a reason for hiding this comment

satya164 commented Jan 15, 2016

ide commented Jan 15, 2016

satya164 commented Jan 15, 2016

davidaurelio Jan 15, 2016

Choose a reason for hiding this comment

alvinthen Jan 23, 2016

Choose a reason for hiding this comment

facebook-github-bot commented Jan 25, 2016

facebook-github-bot commented Jan 25, 2016

facebook-github-bot commented Feb 2, 2016

facebook-github-bot commented Feb 2, 2016

facebook-github-bot commented Feb 2, 2016

facebook-github-bot commented Feb 2, 2016

facebook-github-bot commented Feb 2, 2016

chirag04 commented Feb 3, 2016

vjeux commented Feb 4, 2016

skevy commented Feb 4, 2016

skevy commented Feb 4, 2016

vjeux commented Feb 4, 2016

skevy commented Feb 4, 2016

vjeux commented Feb 4, 2016

bestander commented Feb 5, 2016

lrettig commented Feb 11, 2016

skevy commented Feb 11, 2016

lrettig commented Feb 11, 2016

facebook-github-bot commented Feb 11, 2016