| 11:54 | <littledan> | What’s the motivation for the AbstractModuleSource methods in the ESM source imports proposal? They feel separate from the stated goals. The rationale that I was able to find was:
|
| 15:58 | <guybedford> | littledan: they are in effect loader primitives, that we can do "while we are specifying it". Also effectively replaces the need for eg https://www.npmjs.com/package/es-module-lexer which clearly is needed. |
| 15:59 | <guybedford> | They are somewhat of an orthogonal feature though, that could be worth more explicitly calling out as a use case though certainly. Point taken - I can add some more motivation here around the es-module-lexer use case it solves. |
| 16:08 | <littledan> | but they're defined for all AbstractModuleSources, e.g., also for WebAssembly? |
| 16:09 | <littledan> | I'm also wondering how much you've worked out about the identity of source modules as they're postMessage'd around. Does it go by resolved specifier, or are they cloned the way that module expressions are? |
| 16:10 | <guybedford> | Yes, because these are properties of all cyclic module records |
| 16:10 | <guybedford> | and if Wasm supports top-level await in future or import meta, it might even support those |
| 16:11 | <guybedford> | For the transfer, this is exactly what we are hoping to treat as a Stage 2.7 concern, since it involves interactions with other spec texts |
| 16:11 | <guybedford> | it may likely involve a spec refactoring to more clearly define the module key, which I cover in more detail in the presentation |
| 16:12 | <littledan> | They are somewhat of an orthogonal feature though, that could be worth more explicitly calling out as a use case though certainly. Point taken - I can add some more motivation here around the es-module-lexer use case it solves. |
| 16:13 | <guybedford> | yeah I can call that out |
| 17:14 | <guybedford> | I've posted https://github.com/tc39/proposal-esm-phase-imports/pull/16 to separate this in the proposal readme. |