RFC: Support for 6to5 in Atom


#1

I just submitted a pull request to add support for default transpilation with 6to5 that is on par with Atom’s built-in support for transpiling CoffeeScript to JavaScript: https://github.com/atom/atom/pull/5299. Please consider it an RFC and add feedback there.

Motivation: Over the past several months, I have done a lot of Atom package development using various es.next transpilers. CoffeeScript and ES6 are fairly comparable in terms of the “tidyness” they introduce: class syntax, arrow functions, etc. However, these es.next transpilers add support for important features beyond ES6, such as async/await, type annotations, and JSX. This is a delightful way to develop, and you’re also getting familiar with the future of JavaScript at the same time!

As explained in the commit message, the one catch is that Atom should not automatically transpile all files that end in .js, as that could be wasteful/confusing for packages that are not expecting to be transpiled. In the current version of the PR, I just went with the convention that everything in an atom-es directory will get transpiled. That’s obviously a limiting directory structure, and is naive as it excludes tests. Now I’m thinking that the package.json should enumerate globs or paths that should get transpiled instead so you can structure your package however you like.

An alternative is to require a special file extension (possibly .es for ECMAScript?) and transpile based on that, but I don’t think that would play well with other tools in the real world that expect .js extensions. Also, it implies that such code is not JavaScript, but of course it is: it’s just JavaScript of the future!

Either way, please share your thoughts on the pull request.


#2

How about *.js6 for ECMAscript 6 files? Maybe most existing JS tools will want to look at the resulting transpiled ES5 result. Just the editor wants to treat it as JS, and it should be easy to configure Atom to do it.