Including Closure Compiler in the tools section

85 views
Skip to first unread message

Tyler Breisacher

unread,
Jun 16, 2015, 6:25:32 PM6/16/15
to explor...@googlegroups.com
I've just started skimming through this book and it looks like it will be a great resource for the Closure Compiler team as we continue to improve support for ES6 in the Closure Compiler (https://developers.google.com/closure/compiler/) and encourage more teams inside and outside of Google to use ES6 features in their projects. I look forward to delving into it further.

I just wanted to ask if you had looked at the Closure Compiler's support for ES6 transpilation and typechecking. For transpilation, the command line flags --language_in=ES6_STRICT and --language_out=ES5 are used. We support most of the new language features in ES6 including classes, modules, arrow functions, let/const, generators, rest/spread, for/of, and template strings, and we convert all of those to valid ES5 code (in most cases, valid ES3 code).

To get good typechecking with the Closure Compiler, we recommend you put type information into JSDoc comments (as described in detail at https://developers.google.com/closure/compiler/docs/js-for-compiler). Since the type annotations are in comments, your code is completely valid JavaScript and no transpilation step is required to run it (unless you're using ES6 features and need to run on a browser that doesn't support them) but you still get high-quality warnings, and type-based optimizations.

It would be great to see Closure included in the lists of transpilers and typecheckers in the book. If you have any questions about the project please don't hesitate to ask on this thread or https://groups.google.com/group/closure-compiler-discuss

Thanks!

Axel Rauschmayer

unread,
Jun 28, 2015, 1:21:35 PM6/28/15
to explor...@googlegroups.com
I’ll take a look. Thanks for the tip!

Adam Rackis

unread,
Jun 29, 2015, 1:12:41 PM6/29/15
to explor...@googlegroups.com
Tyler - I've been looking forward to Closure supporting ES6 for sometime - in terms of code compression/optimization.  Is there any idea when that'll be ready?  

It's only a matter of time before some major browsers support ES6 fully enough to start shipping it un-transpiled, so we're looking forward to when Closure will be able to compress our ES6 code just like it does our ES5 code.

Tyler Breisacher

unread,
Jun 29, 2015, 7:24:53 PM6/29/15
to explor...@googlegroups.com
Currently you can use ES6 and the Closure Compiler can convert it to ES5 and then optimize that. But the optimized output will be ES5 so it can't take advantage of any ES6 features to help improve code size. Eventually we'll want the optimized output to take full advantage of ES6 features, and we're starting to work on that; every pass of the compiler will need to understand ES6. Currently most of them crash on some ES6 feature or other. But work is underway! Seehttps://github.com/google/closure-compiler/commit/a0fd0767176e7b5bf580134453be1f269f090b9e for example. It could happen by the end of this year but I'm not making any promises right now.

Another option would be a pass that runs at the very end of the compilation to convert the optimized ES5 to ES6 (e.g. it could convert

var x = {}
x[y] = z;

to

var x = {[y]:z};) but we haven't explored this option in any detail.

Adam Rackis

unread,
Jun 29, 2015, 8:11:41 PM6/29/15
to explor...@googlegroups.com
Thanks for the reply.  We already use babel to transpile down to ES5; I was looking more to the future to when some browsers will support ES6, and we can ship non-transpiled code, which of course would require a minifier (Closure) that understands ES6.

But I'm glad to hear progress is being made.  Am I correct in surmising that the features listed as decided not to support, reports error to comp. are just being pushed off until later? 

Tyler Breisacher

unread,
Jun 29, 2015, 8:22:17 PM6/29/15
to explor...@googlegroups.com
What list are you looking at that says "decided not to support, reports error to comp"? There are indeed features that we don't support for transpilation but we may support once the rest of the compiler understands ES6 directly.

Adam Rackis

unread,
Jun 30, 2015, 10:34:00 AM6/30/15
to explor...@googlegroups.com
Pasted from your github commit below.  But I think your comment answered it.

Is there a reason you all don't just use babel for your transpilation needs?

1. Method defining in obj literal    - supported
2. Computed (dynamic) property names - decided not to support, reports error to comp.
3. Shorthand assignment              - decided not to support, reports error to comp.
4. Super call                        - does not seem to break anything.
5. __proto__                         - "Do not bother with it"

Tyler Breisacher

unread,
Jun 30, 2015, 1:13:34 PM6/30/15
to explor...@googlegroups.com
Linking to that commit may have been misleading. Those bullet points just mean we don't support computed properties or shorthand properties in goog.defineClass. You can still use those features in your code in general. That commit deals with ES6 support for one particular compiler pass, there will be many more such commits over the next several months, for the many other passes of the compiler.

Why not Babel? I'd have to look at the timelines but I don't think it existed at the time we started thinking about ES6 support. Traceur did exist but produced very slow code for some features (I believe that's no longer the case now) so we wanted to make sure we transpiled in a way that didn't hurt speed, code size, or typechecking. Also, if we used a separate tool for transpilation that would complicate the workflow, whereas supporting it directly in Closure Compiler means you don't need to add any new steps to your build process.

Also, we needed to start working on support for ES6 in Closure anyway because we knew that we wanted to typecheck and optimize it eventually, and transpile-to-ES3 was a nice starting point for that support, because we only had to implement parsing, code printing, and transpilation. This allowed a few teams to start using it earlier, and now we're building on that by making sure that every pass in the compiler supports ES6 directly and then we can optimize it and take advantage of all the ES6 features to get really good speed and code size.

Adam Rackis

unread,
Jun 30, 2015, 1:46:17 PM6/30/15
to explor...@googlegroups.com
Very cool - thanks for the info.

So is there a high-level place users like me can track your progress?  I've seen this  https://github.com/google/closure-compiler/wiki/ECMAScript6   (which I see you recently updated) - but it's not terribly detailed (as far as what's left to do in the "check phase")

Tyler Breisacher

unread,
Jun 30, 2015, 1:48:42 PM6/30/15
to explor...@googlegroups.com
Maybe we can set up some kind of "dashboard" showing how many passes are ES6-compatible over time, but we don't really have anything like that right now. I'll try to send updates on closure-compiler-discuss periodically though.

Axel Rauschmayer

unread,
Dec 19, 2015, 7:28:19 AM12/19/15
to Exploring ES6
It took a while, but Closure Compiler is now mentioned in “Exploring ES6”: http://exploringjs.com/es6/ch_deploying-es6.html
Reply all
Reply to author
Forward
0 new messages