Use the same JS language features as React Native

[lacker]

It will make our open source stuff confusing if each project uses a slightly different subset of language features. Tricky to cut n paste from examples, etc. React Native is the trickiest to match because it doesn't actually ship in ES5 form so it's hard to alter the babel config for it. My proposal is that we take ES6 and then cherry-pick individual features til we have the ones React Native uses. If that seems like "the right thing" I can take this on; otherwise what is "the right thing" here?

[gaearon]

I’m 👍 on this if RN is a superset of ES2015.

[lacker]

Sadly babel-preset-react-native is not a superset of ES2015 but it's pretty close. I will keep this a superset of ES2015 and then add in the stuff RN uses, and I will nag the React Native folks separately to add the missing ES2015 features.

[vjeux]

For reference:

• React Native: https://github.com/facebook/react-native/blob/master/babel-preset/configs/main.js#L16
• ES2015: https://babeljs.io/docs/plugins/preset-es2015/

[vjeux]

Missing from react-native:

• transform-es2015-block-scoped-functions
• transform-es2015-duplicate-keys
• transform-es2015-object-super
• transform-es2015-sticky-regex
• transform-es2015-typeof-symbol
• transform-es2015-unicode-regex

Different defaults

• transform-es2015-for-of { loose: true }
• transform-es2015-modules-commonjs { strict: false, allowTopLevelThis: true }

[vjeux]

For React Native, as a philosophy, we want to use es2015 and next. So if those transforms don't break any of our current apps and don't add any weight, we should add them to the preset.

[lacker]

In react-native but afaict not (yet) in create-react-app:

• 'syntax-async-functions'
• 'syntax-class-properties'
• 'syntax-trailing-function-commas'
• 'transform-class-properties'
• 'transform-object-assign'

[vjeux]

• 'syntax-async-functions': we're already embedding regenerator with es2015 and it's already implemented in browsers so should be good to go
• 'syntax-trailing-function-commas': seems like a no-brainer, we should enable it
• 'syntax-class-properties' & 'transform-class-properties': would be nice to wait until end of next week as we're presenting a revised version to tc39. See how it goes.
• 'transform-object-assign': this is a polyfill kind of thing, we don't really need it.

[gaearon]

fully agree with ^^

[lacker]

OK, the problem is the linting. Both async functions and class properties are not supported by eslint. We could use https://github.com/babel/babel-eslint but perhaps that is too nonstandard / not worth it just for this extra bit of compatibility. Any thoughts one way or the other?

[gaearon]

I'm against using babel-eslint for now. It is very fragile (no offense to maintainers, it's just a hard thing to do) and so people have been historically bumping into its issues many times.

We can revisit this later if properties advance in TC39.

[lacker]

OK well you mostly did this in #43 so this issue is all set, with the exception of async. I think it would be cleaner to put that in a new issue so I'll do that