Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WASM32 backend overrides global Worker #4198

Closed
mdekstrand opened this issue Aug 27, 2024 · 2 comments
Closed

WASM32 backend overrides global Worker #4198

mdekstrand opened this issue Aug 27, 2024 · 2 comments
Labels

Comments

@mdekstrand
Copy link

mdekstrand commented Aug 27, 2024

I realize I'm probably operating in very unsupported territory here, but I was doing some experimenting with Sharp on WASM and wanted to report what I found in case the developers want to look at it in the future.

I am experimenting with using the WASM32 backend for Sharp in Deno, mostly to see if it works but also to reduce my use of native modules. Since Deno doesn't support fine-grained control of Node dependencies, I did this test by creating a modified Sharp package to remove all optional dependencies except the WASM32 backend, but the specific problem arises just from loading @img/sharp-wasm32/sharp.node.

Sharp correctly loads the WASM32 backend on Deno but the Enscripten-generated loader code assigns to global.Worker, overriding the Worker class with an incompatible one. The result is that code that uses web workers and loads @img/sharp-wasm32 will no longer work, as new Worker(...) creates an object that is not compatible with the Web Workers API.

Steps to reproduce:

  1. Load @img/sharp-wasm32
  2. Try to use Web Workers with new Worker (specifically, addEventListener is missing)
@lovell
Copy link
Owner

lovell commented Aug 27, 2024

The WebAssembly build of sharp is compiled using ENVIRONMENT_IS_NODE as emscripten currently requires this to generate a Node.js compatible binary (with a global Worker defined, as you've seen).

'-sENVIRONMENT=node',

There's been some discussion around improving Deno support in emscripten at emscripten-core/emscripten#12203 and emscripten-core/emscripten#19359 so this is probably an upstream thing.

@lovell
Copy link
Owner

lovell commented Sep 23, 2024

Closing as I don't think there's anything we can do - I've linked to a couple of upstream issues that you should subscribe to. Happy to re-open if we need to do anything to take advantage of any changes they introduce.

@lovell lovell closed this as completed Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants
@mdekstrand @lovell and others