Decide on --target deno package structure for JSR

[SebastienGllmt]

💡 Feature description

Deno support was added by #1117. Currently, if you use wasm-pack build --target deno, it will generate the following files

project-name.wasm
project-name.wasm.d.ts
project-name.js
project-name.d.ts

However, as of Deno 2.1, you can now run .wasm files directly (and get type safety for them as well), so these files are possibly redundant (depending on if/how Deno adds support for non-numeric types coming from WASM)

This leads to a question: what files do we need, and how should they be structured to be published on a package manager (notably JSR)

💻 Basic example

I think probably the only code that needs to be generated now are three things:

1. project-name.wasm (generated the same way as before)
2. jsr.json
3. (maybe?) some extra glue for non-numeric types

Defining the JSR format for this case

For the JSR file, I think the only content required is this:

{
  "name": "@my-namespace/my-project",
  "version": "1.0.0",
  "exports": {
    ".": "./project-name.wasm"
  },
  "publish": {
    "include": [
      "project-name.wasm",
      "jsr.json"
    ]
  }
}

but I opened an issue on JSR (jsr-io/jsr#858) to make sure there is agreement on what this jsr.json should look like

Clarity around non-numeric types

This issue is primarily around package generation, but you can find the related issue around binding generation here: rustwasm/wasm-bindgen#4287

[dsherret]

This depends on rustwasm/wasm-bindgen#4287

[SebastienGllmt]

@dsherret thanks! I updated this issue to be more scoped on the the JSR question to avoid duplication of the discussion in the wasm-bindgen repo 👍

[NfNitLoop]

if you use wasm-pack build --target deno, it will generate the following files

I don't think the files that get generated are the problem. IIRC, wasm-bindgen can do some nice translation of types from WASM types to JS types, like string, so some wrapper files are necessary for those niceties. (Though they could be .ts files instead of separate .js and .d.ts files? But again, I don't care so much about this part.)

IMO the main bug here is that --target deno is now a regression over the default --target bundler.

--target deno gives you code that looks like this:

const wasm_url = new URL('wasm_box_bg.wasm', import.meta.url);
let wasmCode = '';
switch (wasm_url.protocol) {
    case 'file:':
    wasmCode = await Deno.readFile(wasm_url);
    break
    case 'https:':
    case 'http:':
    wasmCode = await (await fetch(wasm_url)).arrayBuffer();
    break
    default:
    throw new Error(`Unsupported protocol: ${wasm_url.protocol}`);
}

… which will require --allow-read or --allow-net permissions to load.

But --target bundler (or not specifying --target) will give you code that works nicely with Deno 2.1's improved WASM handling:

import * as wasm from "./wasm_box_bg.wasm";

As a workaround, until --target deno is fixed (or just dropped?), developers targeting Deno v2.1+ can/should just use the "bundler" target.