Inconsistent typescript bindings generated for fn with `&mut [u8]` arg

[cam-narzt]

Describe the Bug

The typescript bindings generated for the below function are inconsistent with themselves.

#[wasm_bindgen]
pub fn receive_bytes(file: &mut [u8]) -> Result<(), JsValue> {
    Ok(())
}

Steps to Reproduce

1. Clone https://github.com/cam-narzt/rust-was-bug
2. Run wasm-pack build --target web
3. Run fgrep -RHie receive_ pkg
4. See mismatched function signatures

Expected Behavior

Type signatures of functions should be consistent in exported bindings, per https://github.com/rustwasm/wasm-bindgen/blob/main/examples/without-a-bundler/index.html#L41-L43 the value returned by the init function should be the same as the exports from the module. Using the value returned by init is very preferable because then you know that you haven't introduced a race between the wasm module loading and using it's exports, but the InitOutput interface has what I assume are the internal details function's signatures.

Actual Behavior

The signature of the function is inconsistent.
If I import { receive_bytes } from 'pkg/wasm_bug'; I get function receive_bytes(file: Uint8Array): void, as expected.
If I import init, { InitOutput } from 'pkg/wasm_bug'; and use the result of init, I get receive_bytes: (a: number, b: number, c: number, d: number) => void, which seems to be some internal implementation function for converting between the js and rust types.

[Liamolucko]

The value returned by init is the raw exports of the wasm module, which is not the same as the exports of the main JS file that wasm-bindgen generates. The type declarations are correct; the functions that init returns are internal functions that aren't meant to be used directly.

[cam-narzt]

Well, perhaps it might be worth considering whether there is an opportunity for an ergonomic improvement. Specifically to have the init function exported by the js file return a promise that gives you an object containing the js-wrapped exports of the module rather than the bare ones (possibly with a member with the bare versions, marked as internal).

I'm imagining something like this:

import init from 'pkg/wasm_bug';
const WASM: Awaited<ReturnType<typeof init>> = await init();
WASM.receive_bytes(...blah);

Which has the advantage that you cannot do this:

import init, { receive_bytes } from 'pkg/wasm_bug';
init(); // note no await or then()
receive_bytes(...blah);

or this:

import { receive_bytes } from 'pkg/wasm_bug';
receive_bytes(...blah);

and the output of init() would be (at least in my opinion) less confusing.

I personally believe it is a good idea to make doing the right thing easy and doing the wrong thing hard, and I think that this change (though very much a breaking API change) would go a long way in that regard.