15:39
<Mathieu Hofman>
And Evaluators give us another box, where we can capture the dynamic import behavior for non-modules. Out of these primitives, Compartment can be implemented in user code.
I have been out of this conversation for a while, but thinking about this, I'm wondering if an evaluator.createModuleSource(moduleSourceString): ModuleSource would make sense. It would clearly be tied to making new evaluators, in a way that can be denied independently from ModuleSource existence. However while I believe an evaluator holds its own module graph, I don't think ModuleSource participate in that graph since they're just unevaluated source representation.
15:54
<Kris Kowal>
Indeed. There would be no entanglement between the evaluator and the resulting ModuleSource. There is entanglement between the evaluators and module instance in const evaluators = new Evaluators(); new evaluators.Module(...)
16:00
<Kris Kowal>
That entanglement is evident in a number of ways, including the global object visible to the module, the differentiation between direct and indirect eval (the eval in scope must match the eval of the evaluators instance), the evaluators bequeathed to the module block and module blocks under direct eval, and I believe some other cases. If the evaluators are endowed onto their own globalThis, then the Function, indirect eval, and Module are also entangled, such that (0, eval)('import("x")') invokes the importHook of the evaluators directly and the same story applies to constructed functions.