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
Currently, the ban-deprecated-sync-method fixer converts this:
figma.getNodeById(...).id
into this:
await figma.getNodeByIdAsync(...).id
which is incorrect. It should be:
(await figma.getNodeByIdAsync(...)).id
This problem affects all rules that use addAsyncCallFix. The latter has some heuristics for when to add parens, but the heuristics don't seem to be correct.
There are a couple different solutions:
Easy but clumsy
The easy solution is to simply always add an extra set of parentheses. The parentheses may be redundant in some situations, such as this:
const node = (await figma.getNodeByIdAsync(...))
For folks using prettier or some other code formatter, this is a moot point, but it could be annoying to clutter user code with the extra braces.
Cleaner output, trickier implementation
To avoid adding extra braces, we could try to use AST information to detect when the braces are necessary.
An allowlist approach would enumerate all parent expression types where the braces are necessary. For example:
member access expressions such as (await asyncCall()).member
unary operator expressions such as !(await asyncCall())
maybe more?
Using an allowlist introduces the risk that we may miss some expression types where braces should be added. So, we could use a denylist instead, identifying parent expression types where braces aren't necessary. Examples include:
assignments such as const foo = await asyncCall()
function calls where the await is used as an argument, such as foo(await asyncCall())
etc.
Using a denylist has two downsides: it is probably longer than the allowlist, and risks adding redundant parentheses where they aren't necessary. However, it might be the least-bad option.
It might be worth looking at what prettier or other code formatters do...there might be a tried-and-true heuristic that we can borrow.
The text was updated successfully, but these errors were encountered:
jefflee-figma
changed the title
await-requires-async fix doesn't add parentheses
rules that add await keyword doesn't add parentheses
Mar 6, 2024
jefflee-figma
changed the title
rules that add await keyword doesn't add parentheses
rules that add await keyword don't add parentheses
Mar 9, 2024
Currently, the ban-deprecated-sync-method fixer converts this:
into this:
which is incorrect. It should be:
This problem affects all rules that use
addAsyncCallFix
. The latter has some heuristics for when to add parens, but the heuristics don't seem to be correct.There are a couple different solutions:
Easy but clumsy
The easy solution is to simply always add an extra set of parentheses. The parentheses may be redundant in some situations, such as this:
For folks using prettier or some other code formatter, this is a moot point, but it could be annoying to clutter user code with the extra braces.
Cleaner output, trickier implementation
To avoid adding extra braces, we could try to use AST information to detect when the braces are necessary.
An allowlist approach would enumerate all parent expression types where the braces are necessary. For example:
(await asyncCall()).member
!(await asyncCall())
Using an allowlist introduces the risk that we may miss some expression types where braces should be added. So, we could use a denylist instead, identifying parent expression types where braces aren't necessary. Examples include:
const foo = await asyncCall()
await
is used as an argument, such asfoo(await asyncCall())
Using a denylist has two downsides: it is probably longer than the allowlist, and risks adding redundant parentheses where they aren't necessary. However, it might be the least-bad option.
It might be worth looking at what prettier or other code formatters do...there might be a tried-and-true heuristic that we can borrow.
The text was updated successfully, but these errors were encountered: