Repository navigation
Figure out Synthetic Modules and loaders #526
Description
Activity
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.
That's good feedback, thanks :)
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?
Js code: passing a function. Js source code: passing a string.
Right now we always generate modules via a static/serializable blob. With the removal of
dynamicInstantiatewe need to figure out what we want to do withv8::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.