Experimental Traceur features/ES7 #1939

Closed
OliverJAsh opened this Issue Oct 30, 2014 · 35 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@jlipps

jlipps Oct 30, 2014

👍 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.

jlipps commented Oct 30, 2014

👍 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

This comment has been minimized.

Show comment
Hide comment
@assaf

assaf Nov 8, 2014

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

assaf commented Nov 8, 2014

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

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Nov 8, 2014

Member

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.

Member

rwaldron commented Nov 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@assaf

assaf Nov 9, 2014

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.

assaf commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Nov 9, 2014

Member

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

I can live with this.

Member

rwaldron commented Nov 9, 2014

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

I can live with this.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Nov 9, 2014

Member

Notes...

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

eg.

experimental: ["async", "await" ]
Member

rwaldron commented Nov 9, 2014

Notes...

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

eg.

experimental: ["async", "await" ]
@Naddiseo

This comment has been minimized.

Show comment
Hide comment
@Naddiseo

Naddiseo Nov 14, 2014

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?

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

This comment has been minimized.

Show comment
Hide comment
@assaf

assaf Nov 14, 2014

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

assaf commented Nov 14, 2014

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

@sebv

This comment has been minimized.

Show comment
Hide comment
@sebv

sebv Nov 16, 2014

This seems to work here: #1979

To install it:

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

sebv commented Nov 16, 2014

This seems to work here: #1979

To install it:

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

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Nov 16, 2014

Member

@sebv

This seems to work here: #1979

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

Member

rwaldron commented Nov 16, 2014

@sebv

This seems to work here: #1979

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

@assaf

This comment has been minimized.

Show comment
Hide comment
@assaf

assaf Nov 16, 2014

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.

assaf commented Nov 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@sebv

sebv Nov 16, 2014

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

sebv commented Nov 16, 2014

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

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Nov 16, 2014

Member

@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.

Member

rwaldron commented Nov 16, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@sebv

sebv Nov 16, 2014

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

sebv commented Nov 16, 2014

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

@assaf

This comment has been minimized.

Show comment
Hide comment
@assaf

assaf Nov 16, 2014

@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?

assaf commented Nov 16, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@sebv

sebv Nov 17, 2014

@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).

sebv commented Nov 17, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@assaf

assaf Nov 18, 2014

@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.

assaf commented Nov 18, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@sebv

sebv Nov 18, 2014

@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.

sebv commented Nov 18, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@IanVS

IanVS Mar 8, 2015

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?

IanVS commented Mar 8, 2015

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

This comment has been minimized.

Show comment
Hide comment

abrkn commented Mar 9, 2015

👍

@jugglinmike

This comment has been minimized.

Show comment
Hide comment
@jugglinmike

jugglinmike Mar 9, 2015

Member

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

Member

jugglinmike commented Mar 9, 2015

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

@IanVS

This comment has been minimized.

Show comment
Hide comment
@IanVS

IanVS Mar 9, 2015

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

IanVS commented Mar 9, 2015

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

@jugglinmike

This comment has been minimized.

Show comment
Hide comment
@jugglinmike

jugglinmike Mar 9, 2015

Member

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.

Member

jugglinmike commented Mar 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sebv

sebv Mar 9, 2015

How long for the plugin system to emerge?

sebv commented Mar 9, 2015

How long for the plugin system to emerge?

@CrabDude

This comment has been minimized.

Show comment
Hide comment
@CrabDude

CrabDude Mar 11, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@CrabDude

CrabDude Mar 11, 2015

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

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

@IanVS

This comment has been minimized.

Show comment
Hide comment
@IanVS

IanVS Mar 11, 2015

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

IanVS commented Mar 11, 2015

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

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Mar 11, 2015

Member

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.

Member

rwaldron commented Mar 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@CrabDude

CrabDude Mar 11, 2015

@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. =)

@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. =)

@stefanpenner stefanpenner referenced this issue in ember-cli/ember-cli Mar 14, 2015

Closed

enable async/await/generators meta issue #3529

3 of 9 tasks complete
@callumlocke

This comment has been minimized.

Show comment
Hide comment
@callumlocke

callumlocke Apr 25, 2015

@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

@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

This comment has been minimized.

Show comment
Hide comment
@billinghamj

billinghamj Aug 20, 2015

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".

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

This comment has been minimized.

Show comment
Hide comment
@jugglinmike

jugglinmike Aug 20, 2015

Member

@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.

Member

jugglinmike commented Aug 20, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@billinghamj

billinghamj Aug 20, 2015

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

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

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Sep 6, 2015

Member

@billinghamj nope, sorry.

Member

lukeapage commented Sep 6, 2015

@billinghamj nope, sorry.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Sep 6, 2015

Member

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

Member

lukeapage commented Sep 6, 2015

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

@lukeapage lukeapage closed this Sep 6, 2015

@RealTJ RealTJ referenced this issue in ThibaultJanBeyer/DragSelect Mar 4, 2018

Open

Adding Unit Test #15

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