feat(wasm): compress wasm binaries with gzip to improve load times

[nberlette]

About

Currently the start up time for the WASM implementation is brutal (for example, the typescript plugin file is around 6MB all by itself).

This could be partially mitigated by compressing/decompressing the files as needed - and it could be done using nothing more than the native CompressionStream and DecompressionStream APIs.

While the smallest file size (and best compression) is found with the Brotli algorithm, it's currently not supported by the streaming APIs. I've found the brotli compression side of things to be painfully slow (~15s to compress one of the dprint plugin files); I don't think that's an even tradeoff for the minimal gains of about 10-15% smaller compressed file size.

I'll be implementing this in an upcoming PR, along with .ipynb support as mentioned in #3.

Decisions

These questions need to be answered before this can move forward into reality.

• should filenames have .gz or similar added to denote the compression?
• should we use "gzip", "deflate", or "deflate-raw"?

  ℹ can't change this without fallout once this ships. choose wisely.

Checklist

Things that need to be implemented in order for this feature to ship.

• pipe incoming responses through a CompressionStream (./update-plugins.ts)

  ℹ for incoming wasm from the dprint.dev plugin server (plugin updates)

• pipe responses to the formatter through DecompressionStream (./dprint.ts)

  ℹ for outgoing wasm requested from the client (via a Formatter instance)