Newer versions of wasi:http/incoming-handler are tied to version in StarlingMonkey

Open vados-cosmonic opened this issue 3 months ago • 0 comments

At present, componentize-js will error when users attempt to use a version of wasi:http/incoming-handler that is not being used by StarlingMonkey underneath.

(jco componentize) ComponentError: failed to encode a component from module
$failed to decode world from module

Caused by:
    0: module was not valid
    1: failed to find export of interface `wasi:http/[email protected]` function `handle`
    at componentNew (file:///path/to/project/node_modules/.pnpm/@[email protected]/node_modules/@bytecodealliance/jco/obj/wasm-tools.js:4659:11)
    at componentNew (file:///path/to/project/node_modules/.pnpm/@[email protected]/node_modules/@bytecodealliance/jco/src/api.js:48:12)
    at async componentize (file:///path/to/project/node_modules/.pnpm/@[email protected]/node_modules/@bytecodealliance/componentize-js/src/componentize.js:342:5)
    at async componentize (file:///path/to/project/node_modules/.pnpm/@[email protected]/node_modules/@bytecodealliance/jco/src/cmd/componentize.js:25:24)
    at async file:///path/to/project/node_modules/.pnpm/@[email protected]/node_modules/@bytecodealliance/jco/src/jco.js:485:17

It would be ideal if people could easily update their WASI versions just like if they were using wasi:http manually, but obviously this becomes a problem of trying to support a matrix of wasi:http versions with the version of StarlingMonkey that is used.