Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async shorthand functions cause parsing errors if they are named 'delete' or 'import' #352

Closed
Standard8 opened this issue Sep 1, 2017 · 7 comments

Comments

@Standard8
Copy link
Contributor

Using ESLint, with Espree 3.5.0, we are seeing failures that we were not seeing with 3.4.3.

Example failure:

var foo = {
  async import() {
  }
}

With 3.5.0 this fails with Parsing error: Unexpected token import

Downgrading to 3.4.3 or changing the name of the function to something else, e.g. bar passes.

We've also seen that async delete() {} causes a similar issue.

I suspect this is a regression from #341 given the release notes.

@mysticatea
Copy link
Member

Thank you for this issue.

This has been fixed already on the master branch of upstream: acornjs/acorn#584.
Please wait for the next patch release of acorn, then re-install it.

@Standard8
Copy link
Contributor Author

Unfortunately updating acorn isn't enough as espree seems to be overriding this issue. I've just created #353 with the fix ported across.

@mysticatea
Copy link
Member

Oops, I'm sorry, I had forgotten that.

@not-an-aardvark
Copy link
Member

Closed in 5eb1388

@Standard8
Copy link
Contributor Author

I'm just wondering if there is a likely ETA for when the fix for this could be included in a release?

Currently I'm trying to resolve a few issues with dependencies in one of the modules I'm working on for Firefox, but I'm hitting up against this issue at the moment. Having an ETA would be useful for knowing when I can get back to fixing it.

Thanks.

@not-an-aardvark
Copy link
Member

not-an-aardvark commented Sep 9, 2017

We had been planning to release it along with the scheduled ESLint release next week.

If there's someone waiting on the fix we might be able to do it sooner though.

@Standard8
Copy link
Contributor Author

@not-an-aardvark Next week is fine, it'll be good timing for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants