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
recommendedplugin configuration called@jessie.js/safe-await-separatorwhich only validates that the firstawaitin anasyncfunction is not nested. This way, theasyncfunction 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 otherawaits into future turns, each on their own (empty) call stack.That clear syntactic separation between "synchronous" and "future turn" code in an
asyncfunction provides stronger isolation guarantees than undisciplined code, and makes it easier to reason about the behaviour ofasyncfunctions.Indeed, even JS experts who have used
asyncextensively are sometimes surprised that theawaitkeyword's expression argument is evaluated synchronously up until the next explicitawaitexpression (even across subfunction calls, if there are any). The guarantee is only that the result of eachawaitexpression is received in a future turn.NOTE: The current
@jessie.js/no-nested-awaitrule should be used only for// @jessie-checkcode. 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 defaultrecommendedconfiguration.