Add support for Cloudflare Workers?

[mherger]

I'm trying to use xz-decompress in a Cloudflare Worker. But it fails:

TypeError: Cannot read properties of undefined (reading 'needsMoreInput')
    at Object.pull (.../node_modules/xz-decompress/dist/package/xz-decompress.js:225:35)

Now I see the tagline of this project is "...for the browser & Node" - which CF workers are not. Therefore I wanted to ask whether you could add support for them?

Some of the findings in my discussion with our friend Claude.

Looking at your start() callback:

So pull() is being invoked before start()'s promise (mutex acquire + one‑time WebAssembly.instantiate of the embedded wasm blob) has actually resolved and set xzContext. Per the Streams spec, pull() should never fire until start()'s returned promise settles — but that's exactly what's happening here, in your Cloudflare Worker.

The library's own test suite (Node's stream/web) exercises this exact pattern successfully, including concurrent creation, so the ordering guarantee normally holds. The ContextMutex was clearly added specifically to make concurrent XzReadableStream construction safe — a sign this initialization path is a somewhat fragile area. In workerd (Cloudflare's runtime), a custom ReadableStream with an async start() combined with an immediate pipeThrough/pipeTo chain can end up invoking pull() before the start() promise is awaited-through, which is not spec-compliant but is a known class of issue when mixing JS-constructed streams with Workers' internal piping.

It then suggested the following test to verify the assumption:

const HELLO_WORLD_XZ = "/Td6WFoAAATm1rRGAgAhARYAAAB0L+WjAQALaGVsbG8gd29ybGQKAKHy/8Rqf7/PAAEkDKYY2NgftvN9AQAAAAAEWVo="
const bytes = Uint8Array.from(atob(HELLO_WORLD_XZ), c => c.charCodeAt(0))
const src = new Blob([bytes]).stream()
const s = new XzReadableStream(src)
const r = s.getReader()
console.log(await r.read())

And sure enough this check fails the same way in a worker environment.

Cloudflare has a CLI toolkit wrangler which allows for local testing: https://developers.cloudflare.com/workers/wrangler/

[pimterry]

I'm not using workers myself at all, but I'm not opposed to it. PRs welcome.

Would need to include tests that repro the current error and then validate the fix somehow (wrangler I guess, assuming that reproduces the issue locally) to ensure we don't break it later, and needs to preserve compatibility with the current Node & browser setups too.

[michaelherger]

Guess what? I got it working (with a little help from my friend AI) 😀.

That said the changes were bigger than I thought: Cloudflare doesn't accept dynamic compilation of the WASM. It's expecting it pre-compiled. This is the first time I'm dealing with WASM - so this is pretty far out for me. I don't fully understand whether that changes anything wrt. how you bundle up the module. I believe it would add the .wasm file - which adds another 12kB.

I can create a PR if you want. Might be easier to discuss. Unless you're already saying "NO WAY!".