We should create a rule in the recommended plugin configuration called @jessie.js/safe-await-separator which only validates that the first await in an async function is not nested. This way, the async function has a clear boundary between its "synchronous prelude" that executes on the caller's stack, versus the rest of the body that is split by other awaits into future turns, each on their own (empty) call stack.
That clear syntactic separation between "synchronous" and "future turn" code in an async function provides stronger isolation guarantees than undisciplined code, and makes it easier to reason about the behaviour of async functions.
Indeed, even JS experts who have used async extensively are sometimes surprised that the await keyword's expression argument is evaluated synchronously up until the next explicit await expression (even across subfunction calls, if there are any). The guarantee is only that the result of each await expression is received in a future turn.
NOTE: The current @jessie.js/no-nested-await rule should be used only for // @jessie-check code. Even though it provides the same safety as safe-await-separator, it is much more intrusive and confusing to explain why it is necessary (it isn't, except to make Jessie implementers' lives easier). Thus, it should not be part of the default recommended configuration.
We should create a rule in the
recommended
plugin configuration called@jessie.js/safe-await-separator
which only validates that the firstawait
in anasync
function is not nested. This way, theasync
function has a clear boundary between its "synchronous prelude" that executes on the caller's stack, versus the rest of the body that is split by otherawait
s into future turns, each on their own (empty) call stack.That clear syntactic separation between "synchronous" and "future turn" code in an
async
function provides stronger isolation guarantees than undisciplined code, and makes it easier to reason about the behaviour ofasync
functions.Indeed, even JS experts who have used
async
extensively are sometimes surprised that theawait
keyword's expression argument is evaluated synchronously up until the next explicitawait
expression (even across subfunction calls, if there are any). The guarantee is only that the result of eachawait
expression is received in a future turn.NOTE: The current
@jessie.js/no-nested-await
rule should be used only for// @jessie-check
code. Even though it provides the same safety assafe-await-separator
, it is much more intrusive and confusing to explain why it is necessary (it isn't, except to make Jessie implementers' lives easier). Thus, it should not be part of the defaultrecommended
configuration.