New Babel Transformer

[vipulnsward]

• Added new BabelTransformer to start performing transformation using ruby-babel-transpiler
• Make new BabelTransformer the default transformer
• README changes to reflect new Babel Transformer
• Added deprecation warning for usage of old transformer options
• Move old transformer to JSXTransformer
• Fixed component generator test after changes to new transformer

Fixes #292, #278

[vipulnsward]

Couple of notes about the default transformer options:

• I have referred https://github.com/facebook/react/blob/master/bin/jsx-internal to set these options
• plugins: [constants] is not part of the options right now since we don't have it in the sources, should this be a part in future?

[rmosolgo]

👏 👏 Your implementation looks great!

I don't understand your question about "plugins: [constants]" (I'm not familiar with babel yet), what do you mean by that?

[rmosolgo]

Should we merge this with the "## Coffeescript" section below?

[rmosolgo]

Could we get a few minimal tests for BabelTransformer ? IMO it doesn't have to be much, but it would be nice to have a test to ensure some future change doesn't totally break it!

[netikular]

Sorry to just jump in here, but does this implementation by any chance have any relation to the work done to support es6 in sprockets?

https://github.com/TannerRogalsky/sprockets-es6

Thanks for the great work!

[rmosolgo]

@netikular not at all, "just jumping in" is the beauty of a public project, thanks for speaking up :)

I noticed that project as I was sizing up some options. I didn't it very compelling because:

• the documentation was quite sparse (how do you pass Babel options? how could we make it process .jsx files?)
• the readme wasn't compelling ("This plugin is primarily experimental and will never reach a stable 1.0.")

So, I think it's ok to have a custom transformer!

[vipulnsward]

I have been using this alongside react-rails in our application without any issues, to support es6.
Right now its on track to be merged in sprockets-rails.
I think we can start looking at handling it, after it lands in sprockets-rails master.

[netikular]

@rmosolgo I agree that the documentation is quite sparse, it took me a little while to get it working.

@vipulnsward are you using es6 and JSX together or are you writing your react components in the react-rails style and using the helpers? I noticed that I can rename my JSX files to es6 and with some hoisting up to window get them to work, but it seems like a lot of setup work.

I was just wondering how you are handling working between es6 and jsx and if you are using a module loader or just es6 syntax.

[rmosolgo]

👍 if you guys prefer it, I'm open to it!

[vipulnsward]

Ok, here's the current status-

• One test fails related to coffeescript due to http://babeljs.io/docs/faq/#why-is-this-being-remapped-to-undefined- .
  Babel currently has strict mode enabled by default, hence the breaking of tests. It can be disabled(not recommended), or we would need to find workaround only for coffeescript files.
• plugins: [constants] - this option is defined here - https://github.com/facebook/react/blob/master/bin/jsx-internal#L41 and is a plugin loaded from https://github.com/facebook/react/blob/master/vendor/constants.js and is not included here. This is a question for @zpao I guess, about whether its needed here, I don't think it applies here.
• Test taken care of

[zpao]

The plugins: constants bit in the React build config shouldn't apply here. That's a custom plugin to transform __DEV__ away. We never shipped that with JSXTransformer.

I don't know how custom plugins would hook into this, I'll let you figure that out :) Might be best to not support them initially unless you've tested and documented how it works.

[rmosolgo]

Cool, sounds like we don't need plugins: [constants]. I agree, custom plugins can be a "later" thing.

As for coffee-script, what if we left JSXTransformer as the default for 1.1, then switch the default and add a warning for coffee-script users in 1.2? That keeps things working for people now & keeps our project moving forward.

Either way, I don't think it's a deal-breaker. .coffee users have two decent options: use JSXTransformer or disable strict mode in babel. (And a third very good option: switch to JSX :P)

[vipulnsward]

Custom plugins are as simple as just passing to plugin transform_options.

I think instead of shipping with JSXTransformer as default, we can ship with Babel as default(to be in sync with React) with disabled strict mode to support both coffeescript + JSX and make it explicit that next version default transformer will break CS. Thoughts?

PS: Even if we ship with breaking changes for CS later, Babel can still be used with passing custom transform options - { blacklist: ['spec.functionName', 'validation.react', 'strict'] }

[vipulnsward]

I have pushed an updated version with above changes. I think it makes sense to disable strict by default, to be backwards compatible, since thats how JSXTransformer is handling it.

[vipulnsward]

Travis looks happy now :-)

[rmosolgo]

👍 looks good to me 😀

[rmosolgo]

🎊 the future is now 😄