Is there any way to get the generated promise resolve to Promise when building for JavaScript

[soulsam480]

I'm working on a project where I'm importing gleam directly in TS with the help of https://github.com/Enderchief/gleam-tools package. Everything works fine, but when the type for promise from gleam_javascript package is generated, it's set to any. Which makes sense because this type doesn't have any constructor as per https://github.com/gleam-lang/gleam/blob/main/compiler-core/src/javascript/typescript.rs#L448-L449. But I wanted to know if there's a way to make this point to the Promise type in TS, or is there any plan of doing it automatically via compiler feature in future ?

Thanks.

Screenshot for reference:

[lpil]

There isn't today but we're open to design proposals.

[soulsam480]

thanks, will read on this and try to come up with a proposal.

[soulsam480]

Hacky way

i think I've found a workaround this but we may have some other work to be done to make it work. was going through #4597, well it does convert to jsdoc comments and based on that the hack is to do something like this

/// @returns {Promise<import("../gleam.d.mts").Result<string,string>>}
pub fn wibble_prom() {}

and when it gets compiled

/**
* @returns {Promise<import("../gleam.d.mts").Result<string,string>>}
*/
function wibble_prom() {}

while this does work, but the issue is the generated types don't have the jsdoc comments like the compiled javascript. otherwise seems like a working hack without coming up with a plan to make the types to point to it.

Alternate plan: rough idea of building it to the compiler

similar to @external annotations, we can come up with an annotation for custom types or specifically types that don't have a constructor. below is an example

@type(javascript, "Wibble")
pub type Wibble

// generics ?
@type(javascript, "Wobble")
pub type Wobble(Value)

then for the generated types

export type $Wibble = Wibble

export type $Wobble<Value> = Wobble<Value>

Potential FAQ

1. Why not re-use the @external annotation for types as well ?

• I did think about that, but i feel keeping it specifically for types would make it easier to maintain
• external annotations can target multiple runtimes unlike the proposed @type, would not make sense to make it complicated
• external annotations are intended to be used for implementation aliasing, again mixing that up for types doesn't seem right

2. Why not mention the generic parameter while annotating with @type

• the annotation is more of an alias and less of a full declaration, so the expectation should be set that the target type must be accepting exactly the same number of parameters

3. How are we going to handle generic parameter constraints ?

• again, because we're building this specifically to point toward built-in types, there'd be rare scenarios where this needs to be supported

4. How do we handle migration ?

• I don't think there's any problem with current generated types not being compatible with the new setup assuming there's a mismatch of versions.
• the gleam package manager already makes sure with good version constraints, so this should not be a problem as well

Final notes:

• I do understand that this idea is extremely wishful but I feel with adequate discussion, we may come up with a actionable setup
• I'm willing to help in anyway to make it happen.

Please let me know what you think about this. Thanks.