Experimental Traceur features/ES7

[OliverJAsh]

One experimental/ES7 feature supported through Traceur that I want to start using today is async/await.

What is JSHint’s stance on supporting experimental Traceur features i.e. ES7, e.g. async/await?

[jlipps]

👍 got a repo I'm running in production with many of these experimental features right now:

https://github.com/jlipps/triager

JSHint seems confused by a number of the features I'm using, not all of which are isolated to ES7 I don't think.

[assaf]

We're using async/await as well and would love to see this supported.

[rwaldron]

Supporting "experimental features" in SpiderMonkey has left JSHint with some seriously complex messes to clean up, sort through and/or undo in preparation for ES6. I want to see a comprehensive proposal for supporting things that might churn a bit between now and 2016. What happens if TC39 ultimately rejects async/await? IIUC, @lukehoban has moved on and as such, will no longer be champion of that spec—I haven't seen anyone step up to move it forward. What happens if it even changes in the slightest bit and code that has been using the proposal version becomes slightly incorrect? JSHint will be forced to break back compat for those features and then the authors will file bugs saying that we've broken their use of non-standard, experimental syntax. I'm not saying "no", but I'm definitely saying "not without a plan".

---

@jlipps

JSHint seems confused by a number of the features I'm using, not all of which are isolated to ES7 I don't think.

The best way to get those problems resolved is to file issues here—thanks in advance.

[assaf]

One option is to have async/await option that tracks transpilers that support this feature, independent of any ES spec. I think there's enough interest and willingness to use transpilers that they're not going away.
Even when ES6 becomes finalized we're still going to depend on transpilers for a long while.

Another option is to have an experimental flag that enables next spec features (ES7/8) and those are known to change in accordance with an ever evolving spec.
If the implementation isn't particularly smart about the nuances of async/await and just silently ignores the keywords, it's a significant advancement on what JSHint provides today.
It may not warn me about using await outside of async function, but right now JSHint fails to parse async function declaration, so things that do work (like tracking unreferenced variables) stop working when it comes to async functions or await expressions.
Simply ignoring async and await keywords is a Good Enough solution for me.

[rwaldron]

Simply ignoring async and await keywords is a Good Enough solution for me.

I can live with this.

[rwaldron]

Notes...

• Create new "experimental" flag
• The value is an array of "experimental" things that we simply ignore.

eg.

experimental: ["async", "await" ]

[Naddiseo]

I don't mind taking a stab at adding and maintaining some of the experimental stuff into jshint. I've added async/await support to a local copy, and placed it under a 'traceur' flag.

The only questions I have at the moment:

• Is this something that is wanted?
• I suppose a 'traceur' isn't the best flag, how should I flag it?
• For the tests, should I use fixtures, or add more to the parser.js tests?

[assaf]

I suggest calling it async/await since that's the common name of the feature, and it's not specific to Traceur.

[sebv]

This seems to work here: #1979

To install it:

npm install -f -g https://github.com/sebv/jshint/archive/esnextnext.tar.gz

[rwaldron]

@sebv

This seems to work here: #1979

Maybe, but that's not what we discussed doing in this thread.

[assaf]

To be clear async/await is two keywords for a single feature. In order to use await in the body of the function, the function must be marked as async. This is similar to how generators use yield in the body of a function marked with *. In fact, async/await is just wrapping promises around the generator feature of ES6.

[sebv]

I've just updated the options use experimental config section.

[rwaldron]

@assaf but what happens if either of those two words is changed through the process of proposal refinement (aka. bikeshedding), then it would be smart they we treated them separately.

[sebv]

If there are enough people interested in es7 it's probably better to fork and pull regularly from upstream.

[assaf]

@rwaldron beware adding complexity for an eventuality that's unlikely to materialize.

We know what the keywords are called today, we know the name wasn't a coin toss (it has usage history, e.g. see C#), we know of no proposal to change that.

But more specifically, if a change was to happen, we have no idea how we'll tackle it. It takes a long while to propagate changes through eco-system of tooling and existing code bases. Do we immediately drop support for async/await? Add new syntax but keep feature name (as known)? Add new syntax and rename feature? Run two features side by side until we can discard one?

All these options. Are we taking a guess at what would be the best course of action for a theoretical scenario at an undetermined point in the future? Or do we just go with what we presently know?

[sebv]

@assaf would be good to extract some sort of plugin mechanism, even expose an api. That would make the transition more organic.

But right know it very hard to see where the hooks would be (at least for me).

[assaf]

@sebv not sure I understand what you mean by that. I tried tackling this before, given that async/await are similar to */yield, but ran out of time before I could make any progress. A plugin API could have made it easier, but didn't feel like something that could easily plug & play.

[sebv]

@assaf I think I start to see how to implement that. This is a list not exhaustive of moving part I discovered while implementing async/await:

What you can add (components):

• blockStatement
• prefix
• trigger ( in the code it is called application this is used for arrow function)
• error/warning message
• keywords
  ....

What you can call (utils):

• doFunction
• error method
• advance
  ...

What would be good is for instance instead of adding a block or prefix directly in jshint.js, call a register method on the jshint core engine and use the utils to build your component.

[IanVS]

Hi, I read through a few pull requests and issues regarding support of ES7 async/await, but it seems the conversation has died off. Has there been any other thinking or progress towards support in some shape or form?

[abrkn]

👍

[jugglinmike]

Nothing's been discussed off-line--the conversation on GitHub is the extent of it

[IanVS]

Do I understand correctly that async/await won't be handled (supported or ignored) until a plugin system is developed?

[jugglinmike]

Please remember that the async/await is a proposal for a far-future version of the language and not a specification. Beyond the initial development effort, extending JSHint core with support for this syntax would be a burden on both the maintainers and the consumers. Changes to the proposal will need to be reflected in the user's platform (whether a runtime or a transpiler), the user's code, and also in JSHint itself. It would be hard enough for JSHint to synchronize updates with platform changes, but the problem becomes intractable when you recognize that the userbase will upgrade incrementally. (Proposal changes might seem unlikely, but we're even today struggling with last-minute modifications to ES6's module syntax--see gh-2019 and gh-2036 for a couple examples.)

This is why prior to standardization, the healthiest way for JSHint to support this syntax would be through a plugin system. Once this feature approaches standardization, I expect JSHint's core will be extended to support it natively (just as is happening with ES6 features today).

@rwaldron @caitp @mikesherov If this reasoning reflects your thoughts, I think it would be best to close this issue.

[sebv]

How long for the plugin system to emerge?

[CrabDude]

I certainly appreciate how a request to support async/await may feel like a burden on the JSHint contributors, but I just wanted to provide my perspective and nothing more to encourage support in spite of @jugglinmike's stated concerns:

With the rise in popularity of transpilers (with support for async/await) like traceur and especially babel, the flood of increasingly standardized ESNext features (further encouraging the use of transpilers), the proliferation of promises, and the present support for generators in node.js and io.js (which makes async/await sugar for function* instead of a hack), async/await will see a dramatic increase in usage in the near future.

Further, the popularity of talks like @jhusain's excellent ES7 talks at NodeDay and NodeSummit add to the async/await excitement. At Noderiety and the companies I partner with for node.js training, we're teaching generators/promise first development, and the only thing limiting teaching async/await first is JSHint support.

So obviously I'm bias, but the presence of async/await causes JSHint to go crazy, and makes it almost unusable (admittedly, not the fault or responsibility of the JSHint project). Something as simple as just ignoring (or stripping when linting) the async/await keywords would at least make it possible to use both async/await and JSHint together.

Please consider providing some minimal hack or workaround to at least make JSHint and async/await not incompatible, or consider leaving this issue open and providing some guidance on how to add such a workaround in a manner that would be successfully merged.

Thanks.

[CrabDude]

For anyone in the same boat as me, I was able to get eslint, babel-eslint and SublimeLinter-eslint working.

[IanVS]

@CrabDude thanks, that is also the direction I am moving.

[rwaldron]

Something as simple as just ignoring (or stripping when linting) the async/await keywords would at least make it possible to use both async/await and JSHint together.

This has been suggested and I'm all for it.

[CrabDude]

@rwaldron Excellent. At least this would change this issue from a "wontfix" to an open issue to ignore async/await keywords until it is finalized, for the happy fellow that has time to implement it, wherever he may be. =)

[callumlocke]

@CrabDude

For anyone in the same boat as me, I was able to get eslint, babel-eslint and SublimeLinter-eslint working.

thank you for pointing me in the right direction

[billinghamj]

I'd really like to see some solution for this. Currently it makes JSHint a bit unusable as it just ends up saying "Too many errors".

[jugglinmike]

@billinghamj You can read more about this issue here: http://jshint.com/blog/new-lang-features/ . In the short-term, your best bet is JSHint's ignore directive. You'll be happy to know that async/await advanced to "stage 2" of TC-39's proposal process, meaning it is now on the docket for experimental/unstable implementation in JSHint.

[billinghamj]

@jugglinmike Is it possible to put "ignore" in the config and get it to ignore "async" and "await" as keywords entirely?

[lukeapage]

@billinghamj nope, sorry.

[lukeapage]

@jugglinmike has raised this clear proposal - #2601 which supersedes this. I'm closing for clarity (there are alot of old comments on this issue)