glutinum-org / cli

https://glutinum.net/
59 stars 6 forks source link

union return type in function alias not handled #128

Closed joprice closed 1 month ago

joprice commented 1 month ago

TypeScript

type X1 = (input: string) => Promise<void>;
type X2 = (input: string) => void | Promise<void>;

FSharp

module rec Glutinum

open Fable.Core
open Fable.Core.JsInterop
open System

[<AllowNullLiteral>]
[<Interface>]
type X1 =
    [<Emit("$0($1...)")>]
    abstract member Invoke: input: string -> JS.Promise<unit>

[<AllowNullLiteral>]
[<Interface>]
type X2 =
    [<Emit("$0($1...)")>]
    abstract member Invoke: input: string -> U2<unit, Promise<void>>

Problem description

There seems to be a regression when running locally when compared with the version on https://glutinum.net/, where the Promise type in the type union is not handled, being left as Promise<void> instead of JS.Promise<unit>. This does not happen for the bare return type.

MangelMaxime commented 1 month ago

CLI version is lagging behind compared the the web version.

This is because the web version is released on each commit to main and if you see -preview it means that it has been build with a features/fixes not yet included in the CLI.

The reason for that is it allows people to have access to the latest version of Glutinum while I am working on severals fixes to include in the CLI.

MangelMaxime commented 1 month ago

Another possible difference is how TypeScript is resolved between the CLI tool and the Web application.

I am planning to unify the resolution to make sure to have the same behaviour between both, perhaps the issue is coming from here.

joprice commented 1 month ago

When I mentioned running "locally", I'm building and running it from the main branch using build.sh cli.

MangelMaxime commented 1 month ago

Yes, this is the same things are running it from NPM.

The build.sh cli is just running the CLI tool that will be published on NPM.