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. |
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 |
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:
|
19:24 | <kriskowal> | And can fall back to ShadowRealm for the legit cases where that’s unreasonable. |