Generate from the UI support

[joeblew99]

golang has great generate support.

Any interest is adding this to the GUI ?

[lukehoban]

Agreed. I'm hoping we can do that as part of https://github.com/Microsoft/vscode-go/pull/134 or building upon that. We need all of build, install, run and generate.

[joeblew99]

Awesome. There is an excellent go gen library on github. It generates about 15 different iles for all the things that replaces the need for generics. That would be an awesome test case

[ramya-rao-a]

@joeblew99 Do you mean to have a command to run a simple go generate for current package?

[joeblew99]

@ramya-rao-a i mean a formalised way of being able to initiate code gen at design time, as opposed to compile time or runtime.

The usage scenarios vary based on needs, but there does tend to be archetypes of use cases.

I use the GRPC as my source of truth (along with some annotations) and code gen the following from it:

• RPC
  • Generates the RPC code for communicating from the Front end to the Back end.
• Validators
  • Generates all the Validation code that checks that the data is correct before you persist to the DB.
• Data store
  • Generate all the database code.
• Forms
  • Generates a Swagger web test harness.
  • Generates Forms that use the Material Components.
• Language
  • Generates all language translations & Validation message & Error messages
  • Tooling to help with the workflow.
  • Adapter to integrate with third party translation systems.

Another archetype example is what Visual Studio used to do with WinForms. In the Mkcrosot world it was called "code behind". Basically as you changed a file that represented your GUI widget layout, it woudl generate the event handlers in another "codebind file". I am any c# programmer remembers this. I have the same need. For example when i am editing a QML file, i need the event handlers exposed. Or when i am laying out a tree of Material Components widgets, it would be awesome to have some code generated from that that gives me a list of IDS and type for example.

I am really brain storming here.

Either way, people need to forward gen and reverse gen, and how they need to do it varies based on where their single source of truth is. A classic example of this is for Database ORM tools. DO you gen from the DB upwards to the DAL, or do you gen from your types down to your DAL and into the database of stored procedures.

A simple accessible way to access this from the VCODE IDE would be really amazing. At the moment developers could open a terminal that is watching the file system, and they have a global controller that watches for changes, and then fires off code gen modules. It would be simple for this to be baked into VSCode in the exact same way it was baked into Visual Studio when i used it. But it needs to have decent hooks. So as a golang programmer it would need to evoke the golang compiler and that would then run the standard golang code generation.

Sorry about the biggish explanation, but i wanted to illustrate use cases.

[ramya-rao-a]

Thanks for the explanation @joeblew99, it definitely helped. Also read the Design Doc

If I understand this correctly, as a first step, there should be a way to run the go generate command either on current file or current package.

Next, there should be some way to get this go generate to run every time time there is a change to certain files. This is where I am slightly stumped. How do we decide which files need to be watched for changes to trigger the go generate?

Is it ok to expect the user to specify these files via settings?

[yhuang0]

For my own purpose I just want to have a "go.generateOnSave" option for the current file scope. In addition, a vscode shortcut to run go generate on the workspace/package level manually. I don't think the first version of this needs to be that complicated.

[marwan-at-work]

I like the go.generateOnSave option. I'd also love to see something like Codelens (a button on top of the //go:generate ... comment just like the test functions. I'm happy to put some time into creating a pr if no one is working on it.

[awreece]

Is it ok to expect the user to specify these files via settings?

That would be acceptable to me and appears to be generally accepted for other IDEs. It is certainly an easier solution than attempting to parse the go:generate comment line.

It also a solution that lends itself easily toward building some default configurations, e.g. "if a .proto file is changed, run go generate in the same directory" that would cover 90% of use cases.

[ramya-rao-a]

There hasnt been much progress in this area in the 2 years since the help-wanted tag was added to this issue.

While I do see the merits of this feature, I am afraid I don't believe this extension is the right place for it anymore.

As VS Code and this extension has gained popularity, we have seen a gradual scope creep over the past year. Being a sole maintainer of this project, it is getting a little hard to support all incoming requests and maintaining the ever growing set of features.

Therefore, one criteria I am using now in the triaging process is whether the feature request would make sense as a separate extension. This current feature request appears to be so.

Happy Coding!