coffeescript
coffeescript copied to clipboard
Proposal: Ecosystem: Babel plugin?
From @edemaine on 2017-03-19 16:09
I'm no expert on Babel, but I saw this comment by @ArmorDarks:
I think this won't be an issue at all if CS could be transpiled through Babel. Really, this is one of reason we're leaving CS — it is so damn hard to integrate into nowadays JS pipelines.
Is it feasible / interesting to make CoffeeScript 2 into a Babel syntax plugin?
From @rattrayalex on 2017-03-19 16:44
tl;dr, no, not really.
The CoffeeScript compiler doesn't produce a clean, babel-compatible AST. You could dig into the CS internals, parse out the AST, write a translator that makes it babel compatible, and wrap that in a babel plugin. That sounds pretty hard to me, and I wouldn't be surprised if there were basically unresolvable ambiguities.
Probably the easiest way would be to parse CS entirely into JS, re-parse it into a babel AST, and use that in the babel plugin. It'd be slow, and the sourcemaps would be worthless, but it'd save a build step.
From @ArmorDarks on 2017-03-19 17:03
Probably the easiest way would be to parse CS entirely into JS, re-parse it into a babel AST, and use that in the babel plugin. It'd be slow, and the sourcemaps would be worthless, but it'd save a build step.
Wow, that sounds already painful.
From @kingdaro on 2017-03-19 17:10
That's somewhat of a bummer. One of the reasons I'm hesitant to use CS2 is because of the need for an additional build step on unsupported ES6 environments.
From @rattrayalex on 2017-03-19 17:51
fwiw, I built LightScript from the ground up around Babel; you might give it a try. I'd be eager for feedback over on gitter
From @edemaine on 2017-03-19 18:13
Yes, I was imagining the CS → JS → reparsing as being simple and possible. It's exactly what we're currently doing in CS2 with coffee -c + babel transpilation, right? Wouldn't this still make it easier to use CoffeeScript in existing JS infrastructure as "just another plugin" to Babel?
From @rattrayalex on 2017-03-19 18:31
Worth keeping in mind that babel only processes .js etc by default; you'll have to pass a command-line argument in every time to process extensions too (see https://github.com/babel/babel/issues/3741). eg; babel src -x .coffee --out-dir dist with plugins: ["coffeescript"] in the babelrc. Still more convenient than two-step build, but not seamless.
That said, here's roughly how I'd do it:
import { compile } from 'coffeescript'
import { parse } from 'babylon'
export default function (babel) {
return {
manipulateOptions(opts, parserOpts, file) {
// don't process .js files
// (this would need to be refined)
if (file.opts.filename.endsWith('.js')) return;
opts.parserOpts.parser = (input, options) => {
const jsFromCoffee = compile(input);
return parse(jsFromCoffee, options);
};
}
}
}
I haven't tried it, treat that as pseudocode, but happy to help if anyone decides to give it a shot
From @GeoffreyBooth on 2017-04-10 00:22
This strikes me as a great idea. I don’t think the current compiler should be converted into a Babel plugin, but a Babel plugin that imports it like @rattrayalex’s example would surely make things more convenient for many people. On a current project I use Browserify to merge together .js files and .coffee files in the same project; the more ways to do the same thing, the better.
From @GeoffreyBooth on 2017-11-25 08:30
See coffeescript6/discuss#92 for more discussion of these issues.