Can we land this PR? https://github.com/tc39/proposal-async-context/pull/87#pullrequestreview-2106646155

I guess I haven't considered enough the context of module evaluations

Is there any option other than "the same as async functions"?

if you go to the link in that PR, there are no AsyncContext meetings

I guess I haven't considered enough the context of module evaluations

You’re thinking about https://github.com/tc39/proposal-async-context/issues/93 ?

Yeah I don’t have a better solution. For flow advocates: how bad would it be if we called LexicalVariable “Variable” and did FlowVariable in a follow-on proposal?

Sure but there might not be JS on the stack when rejecting the promise, so at some point earlier you need to save off the context

What do you think of my suggestion there, that we make modules always run in an “original” (empty) context associated with the realm? (And this should apply for import defer as well)

I'm fine with through flow being a follow-on, so long as what lands first is very clearly communicated as not providing that flow type. I feel the naming should more clearly communicate the flow type as AsyncContext.Variable alone does not communicate how it flows at all.

In flow-through semantics you're modelling causality, so you'd just trace back through directly causal code until you reach JS again. In many cases this may just be the construction of an object which emits events or something like that. If you think of it as tracing all execution and not just JS execution then you can always trace a path back through the code to what logically caused it. That could even be something initiated before any JS ran, which would just be a root context.

I find it easiest to think of everything as descending from a root context like that, even if it's empty. OTel does the same thing too with ROOT_CONTEXT being an empty map.

Thinking about people making mistakes or not knowing how to reason about it, or which to pick - I generally expect this to be more of an advanced user feature. I know Shu and others were concerned about the possibility of detrimental performance due to propagating way too many variables. This may not be as "here be dragons" as, say, FinalizationRegistry, but a caveat emptor may still be in order for anyone considering introducing a new variable. I think a bigger concern is cargo-culting snapshot/wrap calls everywhere, and given that even we don't know what the right context is, it seems highly unlikely ordinary users will be able to make heads or tails of it.

I get that this is the intuition, but an actual implementation would have to save and propagate the snapshot forward from the last time JS runs, right?

Sounds like we’re agreeing? (Except I would say that the browser could put stuff in the root context, and different realms could have different root contexts)

Sorry, I meant Shu's concern with AsyncContext at all, not with a specific flow type

Which, from what I understand, is roughly what AsyncContext is doing too.