Feature request: Module APIs about quickjs-emscripten HOT 7 CLOSED

Yeah! I’d really like to enable this. I think the proposed API makes sense, but doesn’t handle the case of defining a module implementation itself using the API. For that we’d need some APIs to create module definition objects too.

I also have a use-case for modules, but I need to be able to load module contents asynchronously. Unfortunately QuickJS doesn’t support an async loading API, so I’ve been working on a new build strategy using Emscripten ASYNCIFY in this PR: #54

My plan is to introduce modules API there. That change also includes new APIs for Runtime and Context, which are conflated by the current QuickJSVm class we offer. The work was blocked by a bug I reported in Emscripten until recently. Now the bug is fixed upstream, but I’m not sure if there’s been a release that contains the fix.

from quickjs-emscripten.

Synchronous string module loading is now passing a test in #54. There’s still some work left on async module loading.

from quickjs-emscripten.

This sounds great!

One downside of relying on just asyncify to accomplish async module loading is that fetching multiple modules in parallel won't be possible. As far as I can tell, that would require support from QuickJS. I've sent a message to the mailing list about that at https://www.freelists.org/post/quickjs-devel/Ability-to-asynchronously-load-modules-allowing-parallel-fetching.

from quickjs-emscripten.

@Macil what use case do you have for quickjs-emscripten where you need to async load modules in parallel? For static imports at the top of the module, the paths can be extracted with a simple AST pass for preloading, using any off the shelf JS parsing library. It’s quite quick and easy to do with ESQuery/Esprima or TSQuery/Typescript.

from quickjs-emscripten.

Partly I was aiming at making something Deno-compatible including working fully with dynamic imports. But dynamic imports aren't something I strictly need now so for now for my project I'm going to go on a route like that.

My project has users send code to a server where it runs continuously in a sandbox. I think I'll either have the users send the result of deno bundle (which bundles a project into a single .js file which would also happen to remove the need for anything to do with module APIs here; this probably sacrifices accuracy of filename/line numbers in stack traces), or send a zip of modules and a json file describing which imports where refer to which modules.

from quickjs-emscripten.

Even with ASYNCIFY this turns out to be a problem. Asyncify can only suspend one promise at a time, but the natural recursive flow of imports violates this restriction:

• eval imports module A
• ASYNCIFY suspend to async load module A
• module A needs to be compiled
• module A requests async suspend to load module B
• Crash

from quickjs-emscripten.

Closed by #54 - please check out the beta 😄.

I plan to merge #59 which changes some minor private APIs and type imports before I cut the next release.

from quickjs-emscripten.