Emscripten wrapper modifies Node.js globals

[donmccurdy]

I'm trying to integrate Draco into glTF-Transform, and have hit an issue with the generated Emscripten wrapper. It includes the following:

process["on"]("uncaughtException",function(ex){if(!(ex instanceof ExitStatus)){throw ex}});process["on"]("unhandledRejection",abort);

The effect of that, unfortunately, is to create noisy output that obscures my own stack traces and user-facing warnings, where my CLI library would normally handle errors. Is it possible to build (and ideally publish) the npm package without this in the wrapper?

[donmccurdy]

These may be the compile flags that would solve my issue:

https://github.com/emscripten-core/emscripten/blob/b053c3f20dc9825ac2cd7e2fd7921862a9367a1e/src/settings.js#L584-L594

[FrankGalligan]

We are planning on a new release this month. We can investigate adding these options.

[donmccurdy]

In the latest release, 1.4.0, I'm seeing a different but still similar line in both the encoder and the decoder:

process.on("uncaughtException",function(a){throw a;});process.on("unhandledRejection",l);

This has a similar effect as before unfortunately, obscuring errors from my own application with a stack trace that seems to come from Draco:

RuntimeError: abort(g: "MY ERROR MESSAGE HERE".). Build with -s ASSERTIONS=1 for more info.
    at process.l (/Users/donmccurdy/Projects/glTF-Transform/node_modules/draco3dgltf/draco_encoder_gltf_nodejs.js:14:152)
    at process.emit (events.js:214:15)
    at processPromiseRejections (internal/process/promises.js:201:33)
    at processTicksAndRejections (internal/process/task_queues.js:86:32)

Both the encoder and decoder include a similar line.

[FrankGalligan]

@donmccurdy Does 1.4.0 not even work now? Or just the same brokenness for you as 1.3.6?

[donmccurdy]

It seems like v1.4.0 just hasn't fixed this particular issue — as far as I can tell it's behaving basically the same as v1.3.6, but I haven't managed to get my own implementation (donmccurdy/glTF-Transform#147) fully updated yet, and haven't tried to update three.js.

[donmccurdy]

Confirmed fixed in v1.4.1, thanks!