wasm-only modules

[SebastienGllmt]

trafficstars

Previously, when using Deno with WASM, you had to create a JS file that would instantiate your WASM module

const wasmInstance = WebAssembly.instantiateStreaming(fetch("./add.wasm"));

However, as of Deno 2.1, this is no longer necessary and you can just import wasm directly while still getting proper type checking: import { add } from "./add.wasm";

Given this, I feel for a lot of WASM packages that are Deno-first, there is no need to include JS/Typescript at all in some cases. For old WASM projects you still need JS glue for non-numeric types, but for newer stuff you can have WIT files that define the interface (type definitions even containing complex types) and then have WASM code that uses the component model to implement the interface. This matches the JSR philosophy of properly typed packages by default.

This fits a bit weird with the jsr narrative of Made for TypeScript & ESM if we're now packaging JSR projects that are just a single .wasm file as the export (or a wasm file and minimal JS glue). However, I feel like Deno definitely won't be only tool to support these kind of wasm-only packages, so I feel there needs to be a natural way to publish these

Is there though for best practices for this kind of WASM-only project? And perhaps JSR will need some additional functionality to generate information around these packages like it does for ESM ones

I added a related issue for this in the wasm-pack repo here: https://github.com/rustwasm/wasm-pack/issues/1454

Some additional thoughts

One of the biggest issues with using WASM packages historically is that tree-shaking is non-existent on the JS/WASM side of things. That is to say, if you have 2 WASM packages that (on the Rust side) depended on the same tool, there is no de-duplication which can lead to very large bundle sizes. Solving this is not entirely in the scope of JSR, but it's something people need to be aware of when it comes to publishing WASM