import of wasi:http@0.2.3 is not disabled with 0.18.3

[alexcasalboni]

I'm doing this:

npx @bytecodealliance/componentize-js@0.18.3 src/index.js --wit wit -o component.wasm -n my-world -d http

but the resulting component still imports wasi:http so it can't run because my host doesn't provide it access to wasi:http.

Note: the component is successfully compiled with no error. You only get an error when trying to execute the component:

component imports instance wasi:http/types@0.2.3, but a matching implementation was not found in the linker

---

If I run the same with the previous version (0.18.2), everything works fine:

npx @bytecodealliance/componentize-js@0.18.2 src/index.js --wit wit -o component.wasm -n my-world -d http

Since jco recently merged the upgrade to 0.18.3 (bytecodealliance/jco#620), I can't use the latest jco@1.12.0 release either.

Any workaround? Or does this need a new release to fix?

Thank you 🙏

[vados-cosmonic]

Hey @alexcasalboni thanks for reporting this, this is indeed a bug/regression -- looking into it now and should have a fix out soon. This will take a version bump to fix and will percolate it's way through Jco as well.

In the meantime the work around is what you've found already (using the older version), but if you have some specific requirements that require the new versions then we can try to find something else!

[alexcasalboni]

@vados-cosmonic thanks for confirming 🙏

We're ok with pinpointing an older version for now.

Look forward to a simple fix in the next release :) Let me know if we can help with anything in the meantime.

[vados-cosmonic]

The PR is up, once I get a review this should make it into 0.18.4 which was already in RCs prepping for release. Should be able to get something quickly. Thanks for the patience and the bug report @alexcasalboni 🙇 !

[vados-cosmonic]

Reopening until the release actually goes out

@alexcasalboni would you mind trying this release: https://github.com/bytecodealliance/ComponentizeJS/releases/tag/0.18.4-rc.1

[tschneidereit]

FWIW, I think we should close issues as soon as they're fixed. That's the way projects usually do it, and what github explicitly supports with the annotations in the UI showing which release a PR became part of.

Yes, that sometimes confuses people, but doing things differently will arguably lead to more confusion in the long run

[vados-cosmonic]

Ah to be clear, I agree on this, I reopened this one because it was the most important breakage that the release was fixing, but in general closing as soon as it's fixed is 100% fine by me.

Arguably if we had some automation around updating issues once their resolutions were released I might want to lean more into fixed=released mindset but yeah the status quo here is fine! I do plan to add some automation that makes comments for when fixes go into releases, but we definitely shouldn't gate on that.

[alexcasalboni]

Hi @vados-cosmonic I tried running this:

npx @bytecodealliance/componentize-js@0.18.4-rc.1 src/index.js --wit wit -o component.wasm -n my-world -d http

but then I got the same error when running the component:

component imports instance wasi:http/types@0.2.3, but a matching implementation was not found in the linker

[vados-cosmonic]

Hey @alexcasalboni so you'd need to run this:

npx @bytecodealliance/componentize-js@0.18.4-rc.1 src/index.js --wit wit -o component.wasm -n my-world -d http -d fetch-event

There is not only the http feature but also the fetch-event feature -- they both need to be disabled if you would like to completely wipe all HTTP capabilities, because the fetch event feature (i.e. addEventListener('fetch', ...) for handling web requests) is on-by-default in componentize-js (and StarlingMonkey underneath).

Also you don't need -n my-world if there is only one world BTW

[vados-cosmonic]

It's unfortunate that we can't truly yank the older version (because there are dependents) and do a 0.19.0 release, so at least for now I plan to continue with releasing this as 0.18.4 even though it contains a CLI breaking change at this point (the addition of fetch-event as a independently controllable feature is what is causing this, essentially).

[alexcasalboni]

Thanks for clarifying 🙏

I confirm it's working great with -d http -d fetch-event 👌

[alexcasalboni]

@vados-cosmonic do you already know if this fix is coming soon to jco too? I'd imagine in v1.12.1?