I just looked into this. I think the only way we can get it to work is by splitting reading from a compressor and writing into it into seperate ops that happen in parallel. This is because a single write may not always correspond to a single read.

How exactly this can be most trivially implemented is still up for debate. I'll revisit this again.

All committers have signed the CLA.

This could be a nice solution for compression in Deno: it's standard compliant and should be more performant than third-party js/wasm modules. As I understand, exposing the zlib in Deno the way Node does is problematic, but this would cover most use cases for compression without exposing zlib.

Please include brotli support.

Please include brotli support.

We wont. it isnt part of the specification

Please include brotli support.

Maybe we can develop std/compress for non standard algorithms like we did std/crypto for non standard digest functions

I assume the most common use case for this API will be online compression of response bodies. In that case, the default compression (zlib's level 6) is good enough, and arguably it's a much better choice than say brotli in most cases due to the complexity/performance trade off.

I used CompressionStream in web application development and found it very fast and convenient, so I would like Deno to implement it as well!
I'm sure it will bring a wonderful experience.

@crowlKats @lucacasonato This is close to working condition now. PTAL.

@ry You either don't have an up to date WPT submodule, or you didn't run ./tools/wpt.ts setup before running WPT tests, as you didn't run some tests. The /compression/decompression-correct-input.tentative.any.html test hangs for me while running locally.

Boiled it down to this test case failing:

const deflateChunkValue = new Uint8Array([120, 156, 75, 173, 40, 72, 77, 46, 73, 77, 81, 200, 47, 45, 41, 40, 45, 1, 0, 48, 173, 6, 36]);
const trueChunkValue = new TextEncoder().encode('expected output');

const ds = new DecompressionStream('deflate');
const reader = ds.readable.getReader();
const writer = ds.writable.getWriter();
const writePromise = writer.write(deflateChunkValue);
const { done, value } = await reader.read();
assert_array_equals(Array.from(value), trueChunkValue, "value should match");
await writePromise;
await writer.close();

The test fails on the line reader.read() with the following error:

error: Module evaluation is still pending but there are no pending ops or dynamic imports. This situation is often caused by unresolved promises.

Pushed the changes required to fix the IDL stuff. The happy case is not working at all though. Always fails with error: Module evaluation is still pending but there are no pending ops or dynamic imports. This situation is often caused by unresolved promises..

@lucacasonato Yes I experienced that too. This seems to be a bug deep inside Deno somewhere, not in this compression stream - there are no async ops.

For example if I run:

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
const deflateChunkValue = new Uint8Array([120, 156, 75, 173, 40, 72, 77, 46, 73, 77, 81, 200, 47, 45, 41, 40, 45, 1, 0, 48, 173, 6, 36]);
const trueChunkValue = new TextEncoder().encode('expected output');
async function main() {
  const ds = new DecompressionStream('deflate');
  const reader = ds.readable.getReader();
  const writer = ds.writable.getWriter();
  console.log("A", Deno.resources());
  await writer.write(deflateChunkValue);
  console.log("B", Deno.resources());
  const { done, value } = await reader.read();
  assertEquals(Array.from(value), trueChunkValue, "value should match");
  console.log("C", Deno.resources());
}
main();

It never gets to the second console.log, but rather the program just exits. If you remove the await on the write.write line, it never gets to the third console.log. Something very wrong is happening.

Mh, that looks like a bug in the TransformStream implementation then. We kinda need to solve that first I guess. I'll investigate that later today.