wails Incorrect module generation for non-main structs

Incorrect module generation for non-main structs

Open acanewby opened this issue 1 year ago • 4 comments

Description

For a typeScript project, when I try and bind a struct from a package other than main as per this guidance, Wails generates an import statement in the TypeScript boilerplate for the context.Context parameter used by my initialization method. However, the linter flags this as an error, since there is no corresponding context exported namespace in models.ts.

To Reproduce

Declare a struct in a non-main package. (I will use Service in a package called config. This struct should have a public method that takes a context.Context parameter
Run wails generate module
Two files are generated:
1. frontend/wailsjs/go/config/Service.d.ts
2. frontend/wailsjs/go/models.ts
Service.d.ts contains an import statement, targeting the context package
models.ts (understandably) has no corresponding exported context namespace

main.go

package main

import (
	"context"
...
	"myApp/internal/services/config"
)

	err := wails.Run(&options.App{
		Title:  "myApp",
...
		OnStartup: func(ctx context.Context) {
			app.startup(ctx)
			cfgSvc.Initialize(ctx)
		},
		Bind: []interface{}{
			app,
			cfgSvc,
		},
	})

Sample struct

package config

import (
	"context"
...
)

type AnalysisConfig struct {
	...
}

type Service struct {
	ctx context.Context
}

func (cfg *Service) Initialize(ctx context.Context) {
	cfg.ctx = ctx
...
}

func (cfg *Service) CreateOrUpdateAnalysisConfig(conf AnalysisConfig) string {
	...
}

}

Generated Service.d.ts

import {config} from '../models';
import {context} from '../models';   // <<---- Unresolvable import
...
export function CreateOrUpdateAnalysisConfig(arg1:config.AnalysisConfig):Promise<string>;
export function Initialize(arg1:context.Context):Promise<void>;

Generated models.ts

export namespace config {
	
	export class AnalysisConfig {
...
	}

}

Expected behaviour

Honestly, I am not sure. I am new to both Go and Wails.

Obviously, generating an unresolvable import is not good.

However, I guess this stems from the following two principles:

Package methods (Initialize() in my case) need to be public to be callable from other packages (main in this case); and
Wails attempts to generate boilerplate for all public methods and all their parameters

While the general principles above seem sound, there appears to be an edge case in that we need a public method when we are trying to invoke OnStartup behavior in wails.Run for a nonmain package but this public method will never realistically need to be invoked from the frontend and so should be excluded from generation.

Perhaps, before the generate phase, main.go could be parsed an an exclusion list built for any methods identified in OnStartup. Then, during generation, the methods could simply be skipped when encountered?

Screenshots

No response

Attempted Fixes

No response

System Details

$ wails doctor         
Wails CLI v2.3.1

Scanning system - Please wait (this may take a long time)...Done.

# System

OS           | MacOS   
Version      | 12.6    
ID           | 21G115  
Go Version   | go1.19.4
Platform     | darwin  
Architecture | amd64   

# Wails

Version | v2.3.1

# Dependencies

Dependency                | Package Name | Status    | Version     
Xcode command line tools  | N/A          | Installed | 2395        
npm                       | N/A          | Installed | 8.19.3      
*Xcode                    | N/A          | Installed | 14.2 (14C18)
*upx                      | N/A          | Available |             
*nsis                     | N/A          | Available |             
* - Optional Dependency

# Diagnosis

Your system is ready for Wails development!
Optional package(s) installation details: 
  - upx : Available at https://upx.github.io/
  - nsis : More info at https://wails.io/docs/guides/windows-installer/

 ♥   If Wails is useful to you or your company, please consider sponsoring the project: