Componentization of app with `wasi/http@0.2.0` fails with version `0.16.0`

[karthik2804]

A guest app with the wit targetting the wasi 0.2.0 world fails to componentize successfully and runs into the following error when using the fetch event handler.

example world

world platform {
  import wasi:http/outgoing-handler@0.2.0;
}

An error occurred during the componentization process: 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/incoming-handler@0.2.0` function `handle`
    at componentNew (file:///Users/karthik_ganeshram/test-app/node_modules/@bytecodealliance/jco/obj/wasm-tools.js:3618:11)
    at componentNew (file:///Users/karthik_ganeshram/test-app/node_modules/@bytecodealliance/jco/src/api.js:37:10)
    at async componentize (file:///Users/karthik_ganeshram/test-app/node_modules/@bytecodealliance/componentize-js/src/componentize.js:419:5)
    at async file:///Users/karthik_ganeshram/test-app/bin/j2w.mjs:113:31

The app build successfully when using ComponentizeJS version 0.15.1.

[tschneidereit]

The issue here is that ComponentizeJS now uses a version of StarlingMonkey that uses wasi-0.2.3 bindings. Ideally ComponentizeJS would be able to handle this situation the same way a runtime would, by satisfying the import with an older version of the package (here: 0.2.0) as long as the actual imported interface is compatible—which it in this case is.

[tschneidereit]

I think this should be fixed with #185. I'm not 100% sure though, as there might be other places where we should check for semver compatible prefixes, but check exact names instead.

[vados-cosmonic]

Hey @karthik2804 I've confirmed a simple component with that WIT builds with version 1.8.3! Happy to re-open if this is still an issue.