closure-compiler: Can no longer call a function named `async`

Looks like the fix to https://github.com/google/closure-compiler/issues/2244 resulted in a regression in that it disallows calling a function called async.

Example:

var x = {async: function(){return 3;}}
x.async()

This now results in the following error:

Parse error. No newline allowed before '=>'

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 9
Comments: 20 (13 by maintainers)

Commits related to this issue

Fix production build Downgrade ClojureScript due to Google Closure compiler breaking core.async - see [1] [2] [3]. 1. dev.clojure.org/jira/browse/CLJS-1953 2. dev.clojure.org/jira/browse/CLJS-1954 3... — committed to dtreskunov/dhis2-wdc by dtreskunov 7 years ago

Most upvoted comments

The ClojureScript compiler is heavy reliant on the Google Closure Compiler. We’re really excited about what the recent developments in processing CommonJS and ES6 modules represent for our community. However, introducing this change relating to the async keyword simply breaks every ClojureScript project out there using the immensely popular core.async library. My opinion is that, by not reserving the keyword for that usage, we could achieve backwards compatibility.

This has come up after we upgraded to the February release and is now a blocker to future upgrades.

At the end of the day, this is obviously your project and you choose how to run it. I just wanted to give my perspective on what the consequences are for ClojureScript.

+22

anmonteiro on Feb 27, 2017

Sounds like this is much more of a problem than yield was. I’m working on fixing it.

+17

brad4d on Feb 28, 2017

fix submitted internally This bug should automatically close with our next push to github.

+11

brad4d on Mar 13, 2017

@ChadKillingsworth definitely. Huge kudos to you for implementing those. We’re on our way to having seamless interoperability between ClojureScript and JavaScript libraries in the very short term.

anmonteiro on Feb 28, 2017

We’re really excited about what the recent developments in processing CommonJS and ES6 modules represent for our community.

Glad to see hard work paying off.

ChadKillingsworth on Feb 28, 2017

@brad4d

The case of async used as a bare function generating an error is incorrect according to the spec, but somewhat intentional on our part, since we wanted to simplify the grammar and discourage general use of a word that is treated specially by the language as a variable name.

I’m using typeahead.js which contains this kind of code:

    function search(query, sync, async) {
        // ...
        async(nonDuplicates);
    }

So the compilation of JS breaks in by project because of this lib, and I’m sure there are a lot of libraries like this one in the wild.

I don’t think it’s wise to impose artificial language restrictions just to enforce best practices. It would most likely break a lot of projects somewhere in the world.

Cheers!

duzun on Feb 28, 2017

@MatrixFrog yield is a reserved JavaScript keyword according to the specification. async isn’t.

anmonteiro on Feb 27, 2017

It might be a bad repro on my part, sorry for misleading you there. I think what I’m actually seeing is the bare async() case.

WRT. your last point, I don’t think introducing a breaking change would be the way to go regarding a keyword that isn’t considered as reserved by the EcmaScript specification.

anmonteiro on Feb 27, 2017