TC39 Module Harmony
2023-05-16
plaintext logs
prev next
source on github
05:12
<Jack Works>
but separately, didn't we want to provide some kind of access to AbstractModuleSource from the global?
I thought if we don't provide any functionality on it, only presented for class heritage, it will be good for the implementors?
05:16
<Jack Works>
not viable... it requires a parser (and it basically breaks CSP?)
10:58
<Luca Casonato>
not viable... it requires a parser (and it basically breaks CSP?)
i would rather imagine a split between loadHook, and instantiateHook (one corresponding to source phase imports, other to source -> instance)
15:22
<Kris Kowal>
not viable... it requires a parser (and it basically breaks CSP?)
The parser would presumably be ModuleSource and the analogues for other languages. But it is true that those can’t attach CSP. But also, pure assets are not in general executable, so CSP might not be germane for the cases you’d want this feature.
15:24
<Justin Ridgewell>

By making the phase part of the explicit syntax, it is possible to statically distinguish between
a full dynamic import and one that is only for a source (where dependencies don't need to be
processed). – https://github.com/tc39/proposal-import-reflection/pull/45/files

This is actually a really good change for bundlers

15:25
<Justin Ridgewell>
We'd be able to support the normal case with static analysis, but it if they did anything dynamic we would have deopted the entire graph. This makes it foolproof.
15:28
<Kris Kowal>
Has implications for the properties of a ModuleSource instance. We could reveal whether each import.<phase> is used.