Motivation

Currently if a function/method returns a generic type like:

pub fn some_fn() -> SomeType<u8> {}
// or
pub fn some_fn() -> Result<SomeType<u8>, JsValue> {}

where SomeType is just plain struct that impls wasm traits manually (not using wasm_bindgen macro on its definition, ie not js class) the generated typescript bindings wont correctly map the return type and doesnt actually include the inner types:

// for both cases above
export function some_fn(): SomeType

Although user can use unchecked_return_type attribute to specify the return type, but this is not really ideal, however if the nested types can be processed regularly like the main type in recursive fashion, this can simply be resolved, so on typescript we would get:

// for both cases above
export function some_fn(): SomeType<number>

Proposed Solution

Implement some logic to parse the return types more than 1 level deep, possibly recursively, until all nested types are parsed and accounted for in generated typescript.
I believe there is amapper currently that maps the rust return types to their equivalent js/ts types, but looks like it just checks 1 level deep, and doesnt go deeper than that, however with some tweaks, the same logic can be applied on nested types to correctly map the return type for the js/ts bindings.
I can think of 2 ways to achieve this:

• We we would use native encoded/decoded WasmDescribe::inform() for return types, we would add a new field to the cli-support::Descriptor like return_generics and during encoding process, we include the generics there, just like we do for ret_inner which we can decode later on and have them available as AdapterType when building the ts sig at very last step.
• next option is to just at the last step of generating ts signature, we will append the generics into the return type, kinda similar to unchecked_return_type but with some tweaks here, we just need to parse the generics into a string fisrtly and keep them in shared::Function and then when building the dts sig, we can just append it to the return type.

PS: I can give it a try if adding this feature is desired

Alternatives

Additional Context

this can be applied to function arguments as well.