TC39 General on 2024-09-12

03:19	<Domenic>	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.
03:29	<Eli Grey>	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. Now that you mention it, if provided, I believe that this could be ergonomic for some of my envisioned use cases. I can't comment in detail
04:48	<Mathieu Hofman>	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. That's one of the goals we have for evaluators, a part of the module harmony effort. It's particularly useful when used with a different global object, and forms the basis of compartments. A shim for compartments has been used in different production environments for light weight isolation of independent parties (in our case combined with frozen intrinsics).
04:51	<Domenic>	This is specifically about within a single realm.
04:53	<Rob Palmer>	Perhaps it would be useful for hot-reloading.
05:38	<James M Snell>	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. This idea has come up a few times, and it certainly does work in Node.js and Deno (and I think bun maybe?) when a query string or fragment is used in the import specifier: `// b.mjs export default import.meta.url // a.mjs import * as a from './b.mjs?1'; import * as b from './b.mjs?2'; console.log(a, b);` We end up with multiple instances of the same module loaded and evaluated as entirely different instances. That said, I've not seen much practical use of this outside of some A/B testing and experimentation.
06:15	<Mathieu Hofman>	This is specifically about within a single realm. Yes, what I'm describing is within a single realm.
06:16	<Domenic>	You're... planning to break the realm <-> global object correspondence??!
06:19	<Mathieu Hofman>	Correct. A compartment can have a different global object. It's basically a set of evaluators which execute with that object as the global
06:24	<Mathieu Hofman>	Compartments is how tools like Lavamoat isolate npm packages from each other, and provide them only with the capabilities they're allowed to by policy. Same realm is necessary for that use case to avoid identity discontinuity issues between realms.