| 00:50 | <kriskowal> | At the last TG3 meeting, I volunteered to figure out what we used exports (a list of all exported names) for on ModuleSource. The answer is somewhat weak… |
| 00:52 | <kriskowal> | The virtual module source “handler” must contain a property that describes all the names it exports and all the specifiers it imports and reexports. |
| 00:53 | <kriskowal> | There is no firm reason that the schema of the virtual module source handler should be identical to a ModuleSource, and we don’t currently use the exports property of actual/vicious ModuleSource instances for anything. |
| 00:55 | <kriskowal> | I personally have a strong æsthetic preference that, if ModuleSource and a virtual ModuleSource communicate the same information that they use the same schema. |
| 00:56 | <kriskowal> | I can imagine using a virtual module source to mock an actual/vicious module source, and for that, I would definitely need to both consume the reflection information off the actual module source and provide the same properties on the handler of a virtual module source. |
| 00:57 | <kriskowal> | So, let’s chalk up “module mocks” as a motivating use case for both module source reflection and virtual module sources. They can’t be done without both features. |
| 00:58 | <kriskowal> | Correction: “module mocks” could be done with “module source reflection”, code generation and the JavaScript “ModuleSource(source)” constructor (in lieu of virtual module sources). |
| 06:12 | <Jack Works> | i like optional import x from 'y', that's read most natural to me |
| 15:12 | <ljharb> | what could have been… from 'y' optionally import 'x‘ |
| 17:15 | <kriskowal> | I can imagine using a virtual module source to mock an actual/vicious module source, and for that, I would definitely need to both consume the reflection information off the actual module source and provide the same properties on the handler of a virtual module source. |
| 17:30 | <guybedford> | when we were working through use cases, we very much did design for this one as a key use case |
| 17:31 | <guybedford> | there's an example here from during some of our loader design discussions - https://github.com/lucacasonato/module-harmony-usecases/blob/main/module-wrapper/main.js |
| 17:31 | <guybedford> | outdated now, but may be helpful? |
| 17:47 | <kriskowal> | very clarifying |
| 17:48 | <kriskowal> | notably does not attempt to instrument live bindings |
| 17:48 | <kriskowal> | but yes, stale but does substantiate exports reflection and would continue to if we dusted it off |
| 20:00 | <kriskowal> | guybedford: first pass at updating the mocking case https://gist.github.com/kriskowal/5c1258095692ce790d40a646e4f83d84 |
| 20:01 | <kriskowal> | Does not attempt to instrument reexports, but that’s feasible. |
| 20:01 | <kriskowal> | Might also be the basis of establishing a module namespace membrane. |