Stream: ComponentizeJS

Topic: Componentizing a module with a top-level Math.random call

view this post on Zulip Ruby Iris Juric (Jul 25 2026 at 02:29):

Hiya! Apologies if this isn't the right spot for this question, but I thiiiiiink this is most relevant place to ask (still getting my head around the ecosystem):

I've got a bundled script that I want to compile into a WASM component. I'm trying to use ComponentizeJS (through jco) to compile it, but I'm running into some issues, and I'm not sure if this is a bug, or expected behaviour.

One of the dependencies included in this bundle contains a top-level call to Math.random. This seems to cause the Wizer step to fail with the following error:

Error: Failed to initialize component (wizer (/nix/store/dygx0sjsarh1ihpc3sff5xj20gxsjcjp-wizer-10.0.0/bin/wizer)):
Error: the `componentize.wizer` function trapped

Caused by:
    0: error while executing at wasm backtrace:
           0: 0x226eb5 - <unknown>!<wasm function 5167>
           1: 0x2fa545 - <unknown>!<wasm function 6201>
           2: 0x2f37a7 - <unknown>!<wasm function 6200>
           3: 0x2fb7a7 - <unknown>!<wasm function 6207>
           4: 0x3a9c49 - <unknown>!<wasm function 7291>
           5: 0x40369d - <unknown>!<wasm function 7732>
           6: 0x402eb1 - <unknown>!<wasm function 7731>
           7: 0x23cf83 - <unknown>!<wasm function 5173>
           8: 0x23c079 - <unknown>!<wasm function 5172>
           9: 0x21f82f - <unknown>!<wasm function 5147>
          10: 0x1ad552 - <unknown>!<wasm function 4447>
    1: Error: attempted to call an unknown imported function: 'wasi:random/random@0.2.10' 'get-random-u64'

       You cannot call arbitrary imported functions during Wizer initialization.

Looking at the StarlingMonkey code, it seems like Math.random is implemented in terms of wasi:random/random's get-random-u64 function, and indeed, manually removing the offending call from the bundle does resolve the issue. This seems unexpected to me - Wizer's documentation claims (emphasis mine):

The initialization function may not call any imported functions. Doing so will trigger a trap and wizer will exit. You can, however, allow WASI calls via the --allow-wasi flag.

ComponentizeJS is passing this flag to Wizer, so it seems like in theory, this should be fine. I did take a look at what that flag does in Wizer though, and I think the issue is that passing that flag sets up implementations for WASI P1 functions, while StarlingMonkey is built against WASI P2. As a result, the call fails since Wizer isn't providing the functions StarlingMonkey needs to evaluate the script.

At this point, I'm not 100% sure how I should be proceeding here. I guess the main thing I'd like to know is - is this behaviour of top-level calls to Math.random in a script being unsupported expected, or is it a bug in one of the various components involved in ComponentizeJS?

view this post on Zulip Tomasz Andrzejak (Jul 27 2026 at 09:24):

Hey, I think the problem is that ComponentizeJS pipeline runs wizer on a core module so it can only support wasi p1 calls and component level wasi p2 random looks like an unknown import. It would be possible to support p2/p3 during wizer pass but that would require reordering the pipeline and running wasmtime-wizer on component not core module.

Somewhat unrelated, there is also an obvious problem with snapshotting random value that is: it is no longer random in the result component - if this is the code you control I would recommend defer or lazily perform the call inside function. If this is dependency code, I imagine using something like rolldown transform could work to fix top level random calls.

view this post on Zulip Ruby Iris Juric (Jul 27 2026 at 09:35):

Ahaaaaa, I see! Yeah, that makes sense - thanks for the rolldown pointer, this is dependency code so I'm probably going to have to resort to some sort of hacky patching (working around it with a pnpm patch for now). Would you happen to know if that pipeline reordering is something ComponentizeJS would be willing to accept as a change? I'd be willing to give that change a go if so.

view this post on Zulip Tomasz Andrzejak (Jul 27 2026 at 09:57):

Would you happen to know if that pipeline reordering is something ComponentizeJS would be willing to accept as a change

I think so, yes, although there are several stages in the pipeline now that assume core module, so it will be far from a trivial change. The AOT path would require similar changes, but weval just recently got support for component input so it's doable.

Also if p3 is an option I think https://github.com/tschneidereit/starlingmonkey-ng will support this out of the box pretty soon. @Till Schneidereit am I right?

Last updated: Jul 29 2026 at 05:03 UTC