Support Babel in all of the same ways as CoffeeScript

[maxbrunsfeld]

We want to move toward writing new code in javascript, not coffeescript. For example: https://github.com/atom/line-ending-selector. But before we start bundling packages written in Babel, we need to improve some infrastructure around it.

Tasks

The CI script

• Make sure it runs specs properly for packages that use babel
• Somehow detect when packages are using Standard Style and lint them properly

Bundled Packages

• Make the build script treat babel source files the same as coffee-script files
• Make the Gruntfile compile babel files

Opting in to Babel

• Create an alternative to the 'use babel' string that fits in better with other babel directives. Maybe this:

/** use babel */
/** @jsx dom */

[maxbrunsfeld]

/cc @kevinsawicki @nathansobo feel free to clarify or correct the above task list.

[nathansobo]

I'm unsure about the wording of the comment header... I see where you're going with @atom but I also think it's just a declaration that Babel is being used for the current document, not necessarily specific to Atom. But I suppose there are a bunch of options to Babel that would need to be specified if this were to be a general flag... I guess it would be nice if those could be enabled by their own directives.

Honestly just supporting /** use babel */ might be enough to blend in more cleanly with their existing header syntax.

[mnquintana]

Just a thought - do we need to have an opt-in for Babel? Would there be any significant harm in passing all JS through the Babel parser? In principle I get why we would want to avoid any unnecessary compilation, but if we're really considering making developing with Babel feel more like developing with Coffee, then it would be nice from a "user" perspective to be able to omit the pragma.

[nathansobo]

@mnquintana My main concern is the overhead of always assuming the need for Babel for every single JS file, both in terms of performance and complexity. I haven't fully thought through the implications of dropping the pragma, but if you or anyone else wants to do an impact analysis on it, I'd be open to discussing it. It just has to be as close to free as possible.

[maxbrunsfeld]

/** use babel */ might be enough to blend in

Yeah, that probably makes the most sense; use the same wording as the other style.

[anaisbetts]

electron-compile uses 'use nobabel' as its directive. One thing you can do is modify your Babel compile-cache to look more like this, where we early-exit from any path involving node_modules:

https://github.com/electronjs/compile-cache/blob/master/src/compile-cache.js#L35

It also might be worth looking into just adopting electron-compile wholesale, it solves a lot of the problems that Atom is trying to one-off per-language, in a more general way, and Atom gets the benefit of improvements that the general Electron Community is using.

[maxbrunsfeld]

@paulcbetts electron-compile seems nice. A couple of thoughts:

1. We would need to ship the compilers with Atom in order to provide dynamic compilation for third-party-packages. But we would want to avoid a dependency on node-scss, since we don't support that language. What do you think about splitting electron-compilers into separate npm modules for the different languages, so that we could depend on some but not all of them?
2. We probably would want to keep babel as an opt-in compiler, for the sake of consistency for package authors. Is there a way that makes sense to configure that, or do you think we'd want to override the built-in babel adapter?

[anaisbetts]

But we would want to avoid a dependency on node-scss, since we don't support that language. What do you think about splitting electron-compilers into separate npm modules for the different languages, so that we could depend on some but not all of them?

It'd be a pretty big PITA to be honest - how about instead we allow you to reach into node_modules and delete node-sass, then we'll make it so that loading the default compiler set will tolerate failures

Is there a way that makes sense to configure that, or do you think we'd want to override the built-in babel adapter?

We could make that configurable, yeah