Support WASM components and WIT files for richer types

[SebastienGllmt]

I would like to be able to import WASM components directly from Deno and get rich type support (including complex object types). Currently it's not supported by Deno, and I can't add it myself due to Deno's lack of custom loader support. Notably, we needs decently advanced custom loaders because the type depends on the WASM file (i.e. I can't tell typescript to give every import the same type like "css -> string". It depends on the WIT of the specific WASM component)

Current state

As of #26668, Deno supports importing WASM files directly

This works great, except that only simple types (ex: numbers) work properly and you cannot have more complex types.

Background

This problem is meant to be solved using WASM Components which allows specifying richer details on what a WASM component expects in order to run properly, and importantly for us what types it expects in its public API (specified through an interface language (IDL) called WIT - WebAssembly Interface Types)

The dream of WASM components and WIT has been around since it reached stage 1 back in May 2022. Progress has been slow, but steady. With WASM components being one of the main topics of talks at the WASM I/O conference, interest is growing

WASM Components, although planned to work with browsers, has mainly come from the server-oriented side of the WASM community. As such, WASM Component version has been done in line with WASI - WebAssembly System Interface. WASI 0.2 which was the main release with WASM components came out in January 2024 (included WASM Components 0.2). WASI 0.3 though is in release candidate as of August 2025, with release planned later in 2025, and WASI 1.0 (which includes Component Model 1.0) is planned for 2026,

Hopes

Although WASM Components are not v1 yet, tooling is already in place to help solve the core reason for this issue creation.

1. Rust programs can already be compiled to WASM Components using cargo-components. This helps Deno have more options for porting code to Rust for efficiency while mitigating previous concerns which is something people have discussed before
2. You can already generate JS interfaces from JCO using jco transpile. However, I cannot hook these into Deno automatically myself because of custom loader limitations
3. Implemented in wasmtime so they're supported in one wasm runtime already

I also think these components can be synergistic with JSR as they can make WASM-first packages in JSR work well with Deno, if Deno supports WASM components as well. It helps with common WASM issues like types, tree shaking, permissions and more