Add an asset entry point

[pimterry]

@pimterry , I are recently working on another kind of entry for the web environment of these packages with less "side-effects".
It is in asset.js with another export in package.json, the document is at asset.md, and an example is available at example/webpack-asset.
Do you think it is fine and can I open a PR for the new entry?

Originally posted by @myl7 in #18 (comment)

[pimterry]

Just pulling this out as a separate topic @myl7, to avoid confusing that thread too much.

Can you explain more about how this works, and exactly why it's useful?

Is there a good reason why we'd need to do this here, instead of fixing the target (or adding a new target) in the wasm-pack project itself?

I'd really like to avoid maintaining more and more complicated entrypoints if we can - it would be much better if wasm-pack could handle this properly. That's less maintenance for each of us on these packages, but would also make it much easier for everybody else building wasm packages elsewhere to do the same thing automatically.

[oligamiq]

The asset entry should be like this, as in brotli-dec-wasm.

  "exports": {
    ".": {
      "types": "./index.d.ts",
      "import": "./index.js",
      "default": "./index.js"
    },
    "./web": {
      "types": "./pkg/brotli_dec_wasm.d.ts",
      "import": "./pkg/brotli_dec_wasm.js",
      "default": "./pkg/brotli_dec_wasm.js"
    },
    "./web/bg.wasm": {
      "types": "./pkg/brotli_dec_wasm_bg.wasm.d.ts",
      "import": "./pkg/brotli_dec_wasm_bg.wasm",
      "default": "./pkg/brotli_dec_wasm_bg.wasm"
    }
  },

By doing the above, you can write code like this, which will greatly improve the development experience by allowing the vite side to manage the publication of the asset, etc.

Also, to use it with cloudflare workers, you must be able to specify the path, as per this documentation. In other words, you must be able to create a WebassemblyModule based on the path. The way to do so is to expose the init function.
#6

The code generated by wasm-pack is thought out in this regard, and if you do not want to wrap it on this side of the library, we recommend that you expose it as an export.
In the meantime, I will send out a pull request later as I want to develop with vite.

import init, {
  BrotliDecStream,
  BrotliStreamResultCode,
} from "brotli-dec-wasm/web"; // Import the default export
// @ts-ignore
import brotli_dec_wasm_bg from "brotli-dec-wasm/web/bg.wasm?wasm"; // Import the wasm file

const promise = init(brotli_dec_wasm_bg); // Import is async in browsers due to wasm requirements!

[oligamiq]

#40

With the changes you see in this pull request, I am able to write code like this.

// @ts-ignore
import init, { decompress, compress } from "brotli-wasm/web"; // Import the default export

// @ts-ignore
import brotli_dec_wasm_bg from "brotli-wasm/web/bg.wasm?wasm&url"; // Import the wasm file

console.log("brotli_dec_wasm_bg", brotli_dec_wasm_bg);

const promise = init(brotli_dec_wasm_bg); // Import is async in browsers due to wasm requirements!

export const brotli_compress = async (data: Uint8Array) => {
	await promise;
	return compress(data, {
		quality: 11,
	});
};

// export const brotli_compress = () => {};
// export const brotli_decompress = () => {};

export const brotli_decompress = async (data: Uint8Array) => {
	await promise;
	return decompress(data);
};

cloudflare docs:
https://developers.cloudflare.com/workers/runtime-apis/webassembly/javascript/#use-from-javascript
https://developers.cloudflare.com/workers/wrangler/bundling/#including-non-javascript-modules

Also, to use it with cloudflare workers, you must be able to specify the path, as per this documentation. In other words, you must be able to create a WebassemblyModule based on the path. The way to do so is to expose the init function.