Proposal: Offer Babel transpilation within the CoffeeScript compiler?

[GeoffreyBooth]

So inside Cakefile we already have a function transpile that takes JavaScript input (the output from the CoffeeScript compiler) and pipes it through Babel, to get a more compatible JavaScript output. We’re currently using transpile to generate the browser compiler .js file, and the code for the docs site.

What if we added a flag (shudder) that told the compiler to run its final output through transpile before returning or saving it? Then people could use the CoffeeScript 2 compiler without necessarily needing to wire together a build chain. We would also need to provide some way for the user to set Babel’s options, probably via babelrc.

Some concerns:

• We currently have no production dependencies, and we like it that way. But we could add Babel to the optionalDependencies key in package.json, so that Babel wouldn’t get automatically installed; and if compile is run with this new flag, we could throw an error if Babel isn’t require-able.
• The current uses of transpile don’t bother with source maps, but we would want to make sure that source maps work with this. There’s some great code in the Meteor CoffeeScript package that sends code through the CoffeeScript compiler, then through Babel, and merges the source maps from each compiler. We would probably want to adapt this.

The latter point is probably the strongest reason to do this. I’m still waiting on some good examples from #4615, so I don’t know how good or bad the current situation is regarding source maps surviving double compilation (CoffeeScript then Babel); but if it’s not great, then maybe this is something we should take on, as source map juggling is probably beyond the capabilities of most build chains or the developers assembling them.

[lydell]

If all of these things are true ...

• Babel isn’t automatically installed
• --transpile (or --babel or whatever we end up) gives a really nice error message if Babel isn’t installed
• Complete Babel customization is available through .babelrc is available
• Source maps Just Work™

... I think this sounds like an awesome feature.

I feel like we should decide on this before the 2.0 release, and possibly even implement it before the 2.0 release since it makes things a lot easier to get started.

[GeoffreyBooth]

Yeah, I was thinking about this whole writing the docs. It would make the docs so much easier to write if we didn't have to keep referring to “and wire up your build chain to use Babel.” That's probably a sign.

If we really want to make things easy, we could make the Babel transpilation enabled by default. The issue there would be how to do that without forcing Babel to be a dependency. Maybe the transpilation happens automatically if Babel is installed? Then the docs get very easy, they just need to say that Babel should be installed. The flag would only be needed then if you wanted to disable transpilation while Babel is installed.

This would also open up new possibilities for our tests. All the JSX and modules tests could get rewritten to compile with transpilation on, and the result executed (rather than compared as a string).

[jashkenas]

Precisely what CS2 output features do we depend on Babel to compile?

[GeoffreyBooth]

It’s a question of what runtimes you want to support. Modules and JSX are unsupported by any runtime, though I guess modules are beginning to be supported in browsers, if not Node. Async functions are only supported by Node 7.6+ and Chrome 55+ and other very new browsers.

You can use the CoffeeScript compiler itself as a proxy for general ES2015 features, as it uses arrow functions and default values and destructuring and lots of other common features, if not generators and async functions. But the CoffeeScript compiler doesn’t run at all in Node 4, only 6 and above. The browser compiler doesn’t run in Safari 9, only 10+. Node 4 and Safari 9 are each only two years old.

So CS2 doesn’t “depend on” Babel, per se. In #4697 I made it an optional dependency, and you can run the CoffeeScript compiler without it (but you wouldn’t be able to use the --transpile option in that case). Adding a Babel transpilation option lets people use the coffee command as their entire build chain in CS2 like they currently do. Admittedly that’s less important nowadays as any serious project will use a proper tool like Webpack or Gulp, but I think it’s important to have as low a barrier to entry as possible to encourage casual use. It certainly makes the docs a lot easier to write, as I can just say “use --transpile“ rather than having to explain build chains etc.

[GeoffreyBooth]

To answer your question another way: the cake build:docs and cake build:browser tasks depend on Babel, to transpile and minify the docs code and the browser compiler. Those are the only ways in which the CoffeeScript codebase depends on Babel (until #4697).

I was wondering if it made sense to somehow let the user choose which transpiler they wanted to use, for example if they prefer Traceur (which also has the required inputSourceMap option, which Bublé lacks). But I’m thinking . . . no. If they want to use Traceur or some other hot future transpiler, they just need to set up a build chain, like how you would pipe through Traceur now without #4697. I don’t want the CoffeeScript compiler to become Webpack. Most Node modules don’t provide options for users to choose their dependencies, and it’s easier for us to support only one transpilation path rather than need to build and test and support several (since they all have slightly different APIs). If in a year or two or three Babel falls by the wayside and something else rises in its stead, we can just refactor what --transpile uses under the hood.

[lydell]

This can be closed now, right?

[GeoffreyBooth]

Yes. Fixed by #4697.