fix(await-async-events): false positive reports on awaited expressions evaluating to promise #890
+173
−24
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checks
Changes
In
await-async-events
,await-async-queries
andawait-async-utils
when determining whether a promise is handled the checks are performed on a parent expression that evaluates to the call expression returning a promise instead of always the call expression. In the following cases the parent expression is used instead.This change does not eliminate false positives from the three
await-async-
rules. The rules are fundamentally written in a brittle way where they look for specific reasons not to report and default to reporting. This means the rules are not robust against changes to the language so even if we defined perfect behaviour for all cases in current JavaScript a new language feature could introduce false positives again.For the rules to be robust and guaranteed not to report false positives they would have to default to not report unless they find a specific reason to report. In 4d878d1 I took this approach but I noticed the other two rules seem to have a requirement of reporting in some unsafe cases (e.g.
expect(query).toBeInTheDocument()
) so I reverted the changes and opted to carve out exceptions for specific cases instead. Whether the rules ought to be safe with regard to false positives or if they're intentionally opinionated is another conversation. I left the safer approach in the commit history in case we want to revisit that idea. Let me know if you prefer a neatly squashed commit history instead.Context
@sjarva invited me to contribute and I picked an issue off the top.
Fixes #887
Although the bug report was about conditional expressions the same bug could be reproduced with other expressions as well. This PR covers all the cases I could think of.