12:14
<Luca Casonato>
Yes, but be careful that import foo; export default foo only works if the module actually has a default export
12:15
<Luca Casonato>
so the redirect module has to be dependant on the module you are redirecting
12:23
<nicolo-ribaudo>
Also, you need to use export { default } from "X" otherwise you break the live binding
12:39
<Aapo Alasuutari>
Ah, trying to re-export a nonexistent default export is presumably a runtime error? Luckily in my case I do know default exports exist but yeah... That's a slight problem.
12:52
<nicolo-ribaudo>
I remember some sort of export ** from "x" proposal to also export the default if present
12:52
<nicolo-ribaudo>
It might be worth re-bringing it up
13:22
<Aapo Alasuutari>
Or `export "x"`?
22:58
<kriskowal>
Opinion sought: Should source.imports() include all of source.reexports()?
22:59
<kriskowal>
My tentative opinion is that imports should include reexports, on the grounds that one would consult imports() for every dependency and reexports() would be consulted for purposes of expanding upon exports() to build namespaces when linking. There doesn’t appear to be a downside to the redundancy.
23:04
<ljharb>
seems strange, "reexports" to me implies you need all three to make a complete picture
23:04
<ljharb>
iow "exports" and "reexports" should either be distinct sets, or, we'd just have "exports" but it'd tell you which export names were re-exported from where
23:18
<kriskowal>
exports and reexports are non-overlapping. exports is names and reexports is import specifiers
23:19
<kriskowal>
imports and reexports overlap since they’re both lists of module import specifiers
23:20
<kriskowal>
the distinction is moot for wasm.module since they don’t have reexports to deal with
23:20
<kriskowal>
so there’s likely to be code that relies on imports() producing a complete list of dependencies
23:22
<kriskowal>
but i can see a case for new ModuleSource(export * from 'x').imports() => [] and .reexports() => ['x'] from a DRY perspective (which is not mine)