Brett (Jun 27 2025 at 15:35): Brett (Jun 27 2025 at 15:35):I'm trying to see if I can get a simple script using @react-pdf/renderer compiled using jco. I've got a repo with my setup but I'm hitting the following error:
Exception while evaluating top-level script
uncaught exception: undefined
Additionally, some promises were rejected, but the rejection never handled:
Promise rejected but never handled: (void 0)
Stack:
Error: the `componentize.wizer` function trapped
Caused by:
0: error while executing at wasm backtrace:
0: 0x7fab79 - <unknown>!<wasm function 13385>
1: 0x7fb4fb - <unknown>!<wasm function 13403>
2: 0x21316 - <unknown>!<wasm function 112>
3: 0x20637 - <unknown>!<wasm function 110>
4: 0xb289 - <unknown>!<wasm function 91>
5: 0x23fbb5 - <unknown>!<wasm function 5192>
1: Exited with i32 exit status 1
(jco componentize) Error: Failed to initialize the compiled Wasm binary with Wizer:
Wizering failed to complete
I don't think my code is trying to use any node-builtin that can't be polyfilled, so I wanted to see if anyone had any ideas on whether or not this is possible, and what a potential fix could be
Tomasz Andrzejak (Jun 30 2025 at 14:38):Hey! Could you try to pass --debug-starlingmonkey-build to jco componentize command so that we can see the symbol names in the trace?
Brett (Jun 30 2025 at 15:13):Yup here you go:
Caused by:
0: error while executing at wasm backtrace:
0: 0x8e6cde - <unknown>!__wasi_proc_exit
1: 0x8e69d5 - <unknown>!_Exit
2: 0x8e7e60 - <unknown>!exit
3: 0xe994 - <unknown>!api::Engine::abort(char const*)
4: 0xe714 - <unknown>!api::Engine::Engine(std::__2::unique_ptr<api::EngineConfig, std::__2::default_delete<api::EngineConfig>>)
5: 0xc935 - <unknown>!wizen()
6: 0xcb0d - <unknown>!__wizer_initialize()
7: 0x25045a - <unknown>!componentize_initialize
1: Exited with i32 exit status 1
(jco componentize) Error: Failed to initialize the compiled Wasm binary with Wizer:
Hey Brett thanks for providing the information so far! Would you mind making an issue on the componentize-js repo?
https://github.com/bytecodealliance/componentize-js
Jco uses componentize under the covers, and so this would probably go best there!
That said, to your actual problem -- can you try a project that uses pdfkit directly https://github.com/foliojs/pdfkit ?
It looks like react-pdf/renderer is a wrapper around that, and I wonder if some React setup that may expect some builtins (ex. browser builtins) is being triggered.
Brett (Jul 01 2025 at 13:49):Sure thing, will add an issue in a moment.
In terms of using pdfkit directly, I gave that a go and ran into seemingly the exact same error. I've updated this repo to include the pdfkit example
UPDATE: Actually looking closer it does seem like my current setup is hitting a browser API issue on the pdfkit specific example, going to try and fix that before creating the issue
Brett (Jul 01 2025 at 14:40):Okay so it's looking like the initial problem is with browser APIs because attempting to build the pdf-kit example I get:
Exception while evaluating top-level script
pdfkit.js:1975:7 ReferenceError: navigator is not defined
Additionally, some promises were rejected, but the rejection never handled:
Promise rejected but never handled: navigator is not defined
So I've tried stubbing navigator with an empty object like so:
globalThis.navigator = {};
Which then leads to a new error:
Exception while evaluating top-level script
pdfkit.js:36455:3 TypeError: can't access property "AbortSignal", exports$o is undefined
Additionally, some promises were rejected, but the rejection never handled:
Promise rejected but never handled: can't access property "AbortSignal", exports$o is undefined
Stack:
dew$n@pdfkit.js:36455:3
dew$m@pdfkit.js:36469:49
dew$15@pdfkit.js:41733:7
dew7@pdfkit.js:41862:24
@pdfkit.js:41893:16
Error: the `componentize.wizer` function trapped
Which is coming from the following generated code:
const {
AbortController,
AbortSignal
} = typeof self !== "undefined" ? self : typeof window !== "undefined" ? window : (
/* otherwise */
void 0
);
exports$o = AbortController;
exports$o.AbortSignal = AbortSignal;
exports$o.default = AbortController;
return exports$o;
Which seems like it's not yet implemented in StarlingMoney. So mystery solved I think, but unfortunately doesn't seem like its currently possible
Milan (rajsite) (Jul 01 2025 at 20:27):Still experimenting in a library I'm playing with (zenfs) but using abortcontroller-polyfill gave me the globals (don't know for sure if the polyfill;s will actually behave well when run):
import 'abortcontroller-polyfill/dist/polyfill-patch-fetch';
Glad you were able to do some more debug @Brett ! @Milan (rajsite) 's right here, finding a way to polyfill the required stuff is probably the best way to move forward.
Given how enmeshed libraries can be with the platforms (NodeJS/Browser) it can be hard to find one that is easy to compile straight to WebAssembly without special platform support. Thankfully StarlingMonkey supports many builtins so this is usually easy, but as you're finding sometimes it doesn't quite work out easily.
Concretely, a way to work through this is to change the script that you run to be a sort of "shim" that adds the missing globals (and hopefully does something reasonable, via polyfill or custom code) to ensure that the core functionality works. It's a bit of a game of whack-a-mole but this at least makes it a bit more iterative/straight-forward to work through.
Victor Adossi (Jul 07 2025 at 16:23):Hey @Brett were you able to get past this? Wondering if we should turn this into an issue or close it out
Brett (Jul 07 2025 at 18:30):Sorry, meant to report back on this last week! Unfortunately I hit the following bug:
Exception while evaluating top-level script
pdfkit.js:29390:26 TypeError: setTimeout can only be used during request handling, not during initialization
Which doesn't seem it can really be shimmed. So this library may just not be a good match for jco
Victor Adossi (Jul 08 2025 at 13:50):Thanks for reporting this -- would you mind making an issue on componentize-js? I think that would be the right place for it, because what I'm assuming here is that pdfkit.js is trying to run setTimeout just... as part of it's initialization?
I wonder if it's possible to delay that code from firing somehow, but this is a case that's worth exploring since I know pdfkit is pretty popular. Worth getting a solution (even if it's a work around)/examining this case
Brett (Jul 09 2025 at 14:08):Done, created the issue! Thank you all for your help!
Victor Adossi (Jul 09 2025 at 14:45):Thank you for surfacing this! Thanks for using the toolchain and I appreciate the contribution :)
Last updated: Dec 06 2025 at 07:03 UTC