Fails on Cloudflare Workers build

[derekperkins]

The browser version relies on document (not available)
The node version relies on the core util module (not available)

cc @tannerlinsley

[pimterry]

Interesting! I wasn't aware of this, I haven't used Cloudflare Workers at all.

I'd happily support Cloudflare Workers if possible, but I'm not sure exactly what environment checks would work for that case. Could you look into it, and open a PR?

[nickbabcock]

The good news is that it's not too difficult. Library authors just need to expose an API entry point where one can pass in a WebAssembly.Module. You can see a cloudflare worker that brotli compresses in a sample project of mine: https://github.com/nickbabcock/cloud-functions/tree/a44260fdbdeab4edda3ca8c84227217bd9dbfb3d/src/brotli

(I'm not a user of this library, but I just happened to see this issue and know of a solution).

[jeromew]

Hello,
I would like to use brotli-wasm on deno in a worker (it is not a cloud-worker, but an Edge Script on an cdn provider, so similar I suppose) but I am a bit lost. I think this might be related to the discussion on cloud-worker so I post it here.

I manage to

import brotliPromise from "https://esm.sh/brotli-wasm@3.0.1";
const brotli = await brotliPromise;
console.log(brotli.compress)

which logs "[Function: x]"

but when I call

const compressedData = brotli.compress(Buffer.from('some input'));

it seems to stop and not do anything.
do you have an understanding about why the library does work in these environments ? I saw the discussion with @nickbabcock but beeing new to wasm I don't quite understand what need to be done.

Thanks for your help !

[jeromew]

ok so I installed deno and tried to launch

import brotliPromise from "https://esm.sh/brotli-wasm@3.0.1";
const brotli = await brotliPromise;
console.log(brotli.compress)

I get

error: Uncaught (in promise) TypeError: WebAssembly.instantiate(): Import #0 "./brotli_wasm_bg.js": module is not an object or function

[pimterry]

To reiterate the above: I'm open to supporting non-Node runtimes, but I don't use any of these personally, so I'm not going to implement this myself.

Feel free to open a PR that to add this if it's something you're interested in. If so, please ensure there are new tests included that cover this runtime (e.g. a new test:deno script in package.json that runs the tests with Deno, or something similar).

If there are problems with specific existing bundles themselves (not just issues with the entrypoint wrapper & package.json config, but the pkg.* directory content) then that's a little more complicated. I would strongly prefer to only use the standard output from wasm-pack, so any solution there should either be a change to a different one of their output formats, or a PR to that upstream repo to fix their output (which would effectively fix the issue for all "Rust in JS via WASM" projects, so it's well worth doing!).

[jeromew]

@pimterry thank you I understand your position. I am new to wasm so not in a very good position for now to PR this.
what I start to understand is that those cloud worker platforms that run wasm sometimes have a limit on the size of the external dependency. It might lead to the need of separate packages for each target (as I understand it now, there is 1 brotli-wasm package that contains the different targets)