00:47
<kriskowal>
A colleague wants to know if we've seen requests from developers, especially non-web JS developers like Node/Deno devs, for "isolated module graphs". That is, same-realm, but you can load a module multiple times in different graphs, executing its side effects each time. I suspect not much but I wanted to ask.
Yes. I’m with Mathieu in the Compartment camp. Agoric, Moddable, and MetaMask so far (that we know about) are using Compartments to isolate globals and module subgraphs. Motivating use cases are to enforce TOFU policies for transitive dependencies and separating a user space host API from guest code. The other case we are paying attention to is per-test module mocks for testing harnesses, and lightweight HMR
00:58
<kriskowal>
Yes. I’m with Mathieu in the Compartment camp. Agoric, Moddable, and MetaMask so far (that we know about) are using Compartments to isolate globals and module subgraphs. Motivating use cases are to enforce TOFU policies for transitive dependencies and separating a user space host API from guest code. The other case we are paying attention to is per-test module mocks for testing harnesses, and lightweight HMR
The notion is to distribute the module map to individual instances that retain their direct import instances. Sources can be reused and reevaluated. https://tc39.es/proposal-compartments/0-module-and-module-source.html
00:59
<kriskowal>
This doesn’t interfere with the host module map but allows a virtualized module graph to grow out from it.
01:54
<snek>
node's vm Module api has use cases (for example, jest uses it for testing) and it can build a new graph in the same realm
01:54
<snek>
but the isolation of the compartment proposal gets in the way of that so its kind of a moot point i think
01:58
<snek>
actually i guess that's the realm proposal not the compartment proposal
15:41
<kriskowal>
I would like the Module and Evaluators proposals (which are coherent with Compartments) to be suitable for the Jest case and I think they can. snek let me know if that sounds achievable and worthwhile.
17:14
<snek>
i don't know the specifics, but i assume as long as they can share objects it will be fine
17:15
<snek>
i would really just love for the vm module in node to be obsolete
19:23
<Mathieu Hofman>

For test runners, in most cases a compartment ought to be sufficient. The main problem is if the test mutates the intrinsics. That can be solved a couple different ways:

  • freeze the intrinsics, but that breaks some legitimate cases, namely tripping the override mistake, and preventing tests of polyfills
  • capture the original intrinsics before running the test, and restore them after, assuming they were left configurable / extensible. That's somewhat heavy handed.
    Of course my preference would be to run everything in a world where intrinsics are frozen, as besides init code, there really should be no need for them to remain mutable for normal code
19:24
<kriskowal>
And can fall back to ShadowRealm for the legit cases where that’s unreasonable.