update: esm source design

[guybedford]

This outlines an initial design sketch for the ESM source phase design, covering:

• module.exports() and module.imports() APIs
• Internal slot for resolution
• Dynamic import() integration rules
• Integration with other specifications such as CSP and structured clone

In an initial version I explicitly defined the CSP property for a [[HostSrc]] internal slot that might be directly checked in the CSP policy rules for example in the Wasm ESM integration.

But on further consideration, CSP as a compilation check, means that by having a source phase import that the compilation guard has already passed - thus if you have a handle to a concrete AbstractModuleSource, then it's already passed through CSP. Similarly for JS, dynamic import of a module guards the module at fetch time, not execution time.

Therefore, it is only the new Worker(module) invocation that needs to be supported here from a CSP perspective as a new construct for permitting CSP sources that have already been vetted statically.

Then I think for that case that we can rather define that the src can be reconstructed from [[HostDefined]] in order to perform the verification here. If there are difficulties figuring that out, then I think that is a CSP integration problem we should handle when we get there, but that we don't necessarily need right now to introduce new machinery to handle it without trying the simpler approach first.

[guybedford]

@nicolo-ribaudo I have added the changes we discussed in todays meting, including the new identity handling.

[lucacasonato]

This document leaves open what happens when you import(esmSource).

[guybedford]

@lucacasonato dynamic import is described in https://github.com/tc39/proposal-esm-phase-imports/pull/3/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R152.