You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Auto-insert await for property accesses on Promise #31450
The proposal here is that all the completions for string should show up. When the user selects a string member, we should automatically await the value, so selecting toLowerCase changes the code to (await x).toLowerCase.
This seems like a good idea but should only be done inside async functions if possible. In the example above, the function is not async so adding an await there would make the code invalid.
Reacted by Daniel Rosenwasser, Titian Cernicova-Dragomir and Pierre PACI
Something else I just thought of: since this would be done via autocompletion, the feature probably shouldn't get any ideas about automatically converting the function to async - doing so is a breaking change in most cases since it forces the function into returning a promise.
Spoke with Daniel Ehrenberg (@littledan) today, and once top-level await lands, we should consider doing this at the top level based on target and module options.
Reacted by Daniel Ehrenberg, Bo Lingen and SlurpTheo
/cc Brian Terlson (@bterlson): Thoughts on this (and the work done already at #32101) as a partial solution for #30646? Personally, I’d still like to surface a quick fix and make sure we have a really good diagnostic message in addition to this, but I think completions are a good first line of defense for the last bullet point you mentioned:
The target of a member expression and T has the member (or maybe the property name is not in Promise).
Activity
fatcerberus commentedon May 18, 2019
This seems like a good idea but should only be done inside
asyncfunctions if possible. In the example above, the function is not async so adding anawaitthere would make the code invalid.DanielRosenwasser commentedon May 18, 2019
Yes, thank you, that was one of the subtler points I forgot to add to this issue. It would be incredibly annoying/unsafe otherwise.
fatcerberus commentedon May 18, 2019
Something else I just thought of: since this would be done via autocompletion, the feature probably shouldn't get any ideas about automatically converting the function to async - doing so is a breaking change in most cases since it forces the function into returning a promise.
DanielRosenwasser commentedon May 22, 2019
Spoke with Daniel Ehrenberg (@littledan) today, and once top-level
awaitlands, we should consider doing this at the top level based ontargetandmoduleoptions.andrewbranch commentedon Jun 26, 2019
Related: #30646
andrewbranch commentedon Jun 26, 2019
/cc Brian Terlson (@bterlson): Thoughts on this (and the work done already at #32101) as a partial solution for #30646? Personally, I’d still like to surface a quick fix and make sure we have a really good diagnostic message in addition to this, but I think completions are a good first line of defense for the last bullet point you mentioned:
bterlson commentedon Jun 26, 2019
I like it a lot, personally. Incrementally addressing the various bullets is fine by me, and I think this is probably one of the biggest rocks.
1 remaining item
Kingwl commentedon Jun 27, 2019
Another quick fix is better, the current completion behavior seems cannot add
asyncmodifier simply as far as I knowxujif commentedon Aug 13, 2019
a suggestion: add a new keyword to a function and translate to js with await all variables.