fix: Prevent type parsing to interfere with package name in typescrip…

[ValentinTrinque]

Before that fix:

The method...

func (h *Handler) RespondToInteraction(interaction interactor.Interaction) {}

... would generate...

export function RespondToInteraction(arg1:number):Promise<Error>;

... because the interaction package starts with int and anything starting with int is interpreted as number as defined here:

wails/v2/internal/binding/generate.go

Lines 130 to 134 in eee6797

	case
	strings.HasPrefix(input, "int"),
	strings.HasPrefix(input, "uint"),
	strings.HasPrefix(input, "float"):
	return "number"

[leaanthony]

Nice find and thanks for the PR! We are encouraging everyone to include tests with PRs to alert us to regressions at a later date. Do you think you could add a test to this PR? We have tests defined in v2/internal/binding/generate_test.go.

Thanks 🙏

[ValentinTrinque]

Yes, of course, I quickly tried, but testing this part is a not super straight forward. I'll see what I can do

[ValentinTrinque]

In the end, that was pretty easy.

[ValentinTrinque]

I rebased against master.

[leaanthony]

Thanks for this. Added a comment. Thoughts?

[leaanthony]

I'm wondering if this would have been easier if we could generate to a map[string]string and use that for testing. This would essentially represent map[filepath]filecontents. Thoughts?

[ValentinTrinque]

Yes, that would have been easier.

I think we could significantly improve the design (and its testability) by splitting the bindings generation into multiple component (with Single Responsibility Principle, in mind).

I already had a look to hit, but wanted to keep this fix refactoring-free.

Here is just my brain dump on the matter.

Basically, the idea would be:

1. A component that parse the go code and build an AST. That already exist AFAIK.
2. A component that translate that Go AST into a JS AST
3. Another component that translate that Go AST into TS AST
4. A component responsible to write the JS AST as JS code
5. Another component responsible to write the TS AST as TS code

The binding code would essentially become, as pseudo code:

func main() {
  writer := fileWriter{}

  goAST := GetGoASTFromBoundStructs({}interface{&Handler{}})

  go func() {
    ast := toJavascriptAST(goAST)
    obfuscatedAST := obsfuscateJavascriptAST(ast)
    code := toJavascriptCode(jsAST)
    writer.Write(code, "Handler.js")
  }()

  go func() {
    ast := toTypescriptAST(goAST)
    obfuscatedAST := obsfuscateTypescriptAST(ast)
    code := toTypescriptCode(ast)
    writer.Write(jsCode, "Handler.d.ts")
  }()
}

That example doesn't take into account the model generation, UPX and all the nitty gritty details. It's just to convey the idea.

Such design definitely will add more loop interaction but I believe the testability, extensibility (adding specific processing, features, etc) and ability to replace each component will increase dramatically.

Also, this is just a draft thought as I haven't looked in the details. I think I saw that part of the existing code is used for Wails runtime to call the methods and all, so it really needs more thoughts and design.

I am of course open to critics :)

[leaanthony]

Let's look at refactoring separately 👍

[ValentinTrinque]

Thanks @leaanthony !

I opened an issue about the refactoring proposal #1953.