Functions & methods

[jordanfowler]

Can tygo generate function & method type definitions? I don't see this anywhere in your README or when using the CLI to generate my types. I understand the fact that Go supports multiple return values while Typescript does not, however, it seems like there should be an elegant solution to this, here's an idea:

• For single-value return types in Go: func Foo() string generate equivalent Typescript: function Foo(): string
• For multi-value return types in Go: func Bar() (string, error) generate Typescript using a tuple return type: func Bar(): [string, error]
• For named-value return types in Go: func Baz() (name string) generate equivalent Typescript: func Baz(): { name: string }

I'm certain you've thought through this already and have much more insight. If you'd like help, I'm happy to throw together a PR.

[gzuidhof]

Hey @jordanfowler,

I imagine it's mostly possible generate the typing of functions, but I'm not sure what the usecase for it would be?
I think there are quite some design decisions about the output that will not be a fit for everybody. For that reason I think it's better if Tygo doesn't support it - but maybe I'm missing some important usecase that vote in favor of it.

If you are doing this at a small scale: I would propose to write your own typings instead of making this tool do it.

[jordanfowler]

Hi @gzuidhof,

Thank you for getting back to me. I should have provided more context about my use case:

• We are working on a JS runtime written in Go (based on https://github.com/grafana/sobek)
• We expose a Go-based SDK to this runtime making it available in JS (works great!)
• We would like to generate the TS types for this SDK binding via a configurable codegen system like yours

It appears this isn't a common use case, so I fully understand if you don't think it's a good fit for tygo to support. If you do feel like this is a good fit, I think the approach to a solution I provided in my original post is a good start. To expand on that approach a bit and to ensure backwards compatibility, this could be an opt-in only feature accessible via //tygo:emit or perhaps a new generator annotation. See example below:

type CoolType struct {
  name string
}

// Assumption: Name method on CoolType is inferred from its receiver (c *CoolType)
//tygo:emit
func (c *CoolType) Name() string {
  return c.name
}

[jordanfowler]

To expand a bit further, //tygo:emit or something similar could support a signature argument:

//tygo:emit name(): string
func (c *CoolType) Name() string {
  return c.name
}