denoland / deploy_feedback

For reporting issues with Deno Deploy
https://deno.com/deploy
74 stars 5 forks source link

[Bug]: sharp doesn't work in deno dploy #626

Open brc-dd opened 7 months ago

brc-dd commented 7 months ago

Problem description

Sharp works fine locally, but on deploy it seems to be trying to find linux-x64 version and crashes.

Steps to reproduce

https://dash.deno.com/playground/useful-clam-72 -- it crashes with Error: Could not load the "sharp" module using the linux-x64 runtime. But if you run the same code locally (deno run --allow-ffi --allow-net server.ts) then it works fine.

Expected behavior

Works fine like it does locally. Not sure if this is a bug or just not supported 👀 Is there a workaround for this?

Environment

deno 1.40.2 (release, aarch64-apple-darwin) v8 12.1.285.6 typescript 5.3.3

ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60

Possible solution

No response

Additional context

No response

lucab commented 7 months ago

Thanks for reaching out. As noted in https://sharp.pixelplumbing.com/install#prebuilt-binaries, the library you are using is implemented by executing separate native binaries/libraries (only on some specific OS and platforms). For sandboxing reasons, the Deploy execution environment does not allow executing arbitrary native binaries (effectively in deploy both --allow-ffi and --allow-run are not allowed and automatically blocked).

If you want to execute some logic not implemented in JS/TS, WASM is the main execution interface supported in the sandbox.

brc-dd commented 7 months ago

sharp now ships with a wasm build too - https://sharp.pixelplumbing.com/install#webassembly 👀 It it usable with deno deploy?

lucab commented 7 months ago

I'm not specifically familiar with this library, but from the link you provided the WASM flavor seems to require multi-threading support (via Web Workers) which is not supported in Deploy: https://github.com/denoland/deploy_feedback/issues/171. So while in general WASM code can run in Deploy, this library instead may not work due to the additional Workers requirement (it may be worth checking if the library has a non-worker fallback mode, not mentioned in the docs).