Figure out Synthetic Modules and loaders

[bmeck]

Right now we always generate modules via a static/serializable blob. With the removal of dynamicInstantiate we need to figure out what we want to do with v8::Module::CreateSyntheticModule. In theory this would be easier for workflows like testdouble if we do expose a way to set the exports of a module directly, however a lot of decisions about where the list of export names etc. are determined is unclear.

[giltayar]

If I understand correctly, a synthetic module would need to not only define the set of named/default exports, but also give a set of operations to execute (in testdouble's scenario, those steps would set the variables the export values). And we can do that either via giving JS code, or by giving the JS source code.

The second option is basically what is being done in testdouble today, except that today it's giving the whole module's code.

The first option is impossible, because it's JS code in the loader worker, and so inaccessible from the main threads.

In any case, at least for testdouble's purposes, it's not a painpoint, and not something that I feel was sorely needed.

Just my 2 cents.

[bmeck]

That's good feedback, thanks :)

[GeoffreyBooth]

And we can do that either via giving JS code, or by giving the JS source code.

I'm sorry, what's the difference between these two?

[giltayar]

Js code: passing a function. Js source code: passing a string.