I had started working on something very similar to this, a higher level wrapper for quickjs-emscripten.
quickjs-emscripten is great, but it's API is deliberately very close to quickjs's C API.
It can be quite difficult to use directly, and implementing support for loading libraries is non-trivial, especially if any of those libraries depend on certain nodejs or browser APIs.
Implementing support for `require()` is tricky, because it's a blocking API, so doing any async IO to fetch module code is not possible unless you either:
- Use the asyncifyed version of quickjs-emscripten(slower and more difficult to use)
- Use blocking IO to load modules(not ideal).
- Pre-load all module files into an in-memory filesystem(which is what is sounds like this lib is doing).
I haven't looked much into how the quickjs-emscripten-sync library works exactly, but automatic syncronization of host and guest functions, seems like it could be a big attack surface, and I worry that it might be possible to escape the sandbox with it somehow.
quickjs-emscripten is great, but it's API is deliberately very close to quickjs's C API. It can be quite difficult to use directly, and implementing support for loading libraries is non-trivial, especially if any of those libraries depend on certain nodejs or browser APIs.
Implementing support for `require()` is tricky, because it's a blocking API, so doing any async IO to fetch module code is not possible unless you either:
- Use the asyncifyed version of quickjs-emscripten(slower and more difficult to use) - Use blocking IO to load modules(not ideal). - Pre-load all module files into an in-memory filesystem(which is what is sounds like this lib is doing).
I haven't looked much into how the quickjs-emscripten-sync library works exactly, but automatic syncronization of host and guest functions, seems like it could be a big attack surface, and I worry that it might be possible to escape the sandbox with it somehow.