fix: allow for use of both manual & fetchEvent based HTTP #247

vados-cosmonic · 2025-07-10T16:32:02Z

This commit updates the componentize-js code to support both fetchEvent and manual based HTTP.

To make this possible we needed to re-introduce a few things:

A feature that represents fetch-event
Allow controlling removal of the the built-in fetch event
Allow skipping checks for manual wasi:http/incoming-handler impls
Add oxc-parser to detect manual impls and toggle fetch-event feature

The docs are also updated to note the changes to API/usage.

src/componentize.js

crates/splicer-component/src/lib.rs

test/cases/fetch-event-server/test.js

crates/spidermonkey-embedding-splicer/src/wit.rs

src/componentize.js

crates/spidermonkey-embedding-splicer/src/wit.rs

crates/spidermonkey-embedding-splicer/src/bindgen.rs

test/cases/fetch-event-server/test.js

crates/spidermonkey-embedding-splicer/src/bin/splicer.rs

andreiltd

Thank you! I wouldn't mind additional tests, for example for pure components that you mention in the docs, but otherwise LGTM! 🚀

src/componentize.js

vados-cosmonic · 2025-07-11T09:05:29Z

Also @tschneidereit before you run into this.. I have already split out the PRs so they're a bit easier to review:

#252
#251
#248

I'll do the required PR fixups regardless of which you merge in what order!

This commit updates the componentize-js code to support both fetchEvent and manual based HTTP. To make this possible we needed to re-introduce a few things: - A feature that represents fetch-event - Allow controlling removal of the the built-in fetch event - Allow skipping checks for manual wasi:http/incoming-handler impls - Add oxc-parser to detect manual impls and toggle fetch-event feature The docs are also updated to note the changes to API/usage.

vados-cosmonic · 2025-07-14T13:45:23Z

Hey @tschneidereit -- I've rebased this to main with all the changes that landed, this should be a very minimal changeset + test now.

tschneidereit

Let's get this landed. There are a couple of things I'd prefer to have different, but absolutely don't want to block getting this in on them:

It'd be nice if we could, on a best-effort basis, detect usage of FetchEvent when auto-disabling support for it. That'd be possible using oxc, but somewhat gnarly. Basically, it'd require walking the AST, finding all function calls to the identifier addEventListener, and checking if the first argument is the string literal "fetch". Obviously there are ways to create both false positives and negatives, but those are unlikely enough for a warning not to be a problem, I think.

The more important thing is that I thought we had agreed to have the parsing happen in Rust instead of JS. That'd both better support using the splicer as a Rust dependency, and be faster.

Again, we should absolutely land this without addressing either of these!

src/componentize.js

vados-cosmonic · 2025-07-14T15:11:50Z

Made an issue so that we don't forget to come back to the fetch event detection to improve it!

#253

vados-cosmonic requested a review from tschneidereit as a code owner July 10, 2025 16:32

vados-cosmonic force-pushed the refactor=wasi-http-detection branch 2 times, most recently from bf0c88d to 16b39ad Compare July 10, 2025 16:56