increase development determinism by using go tool in taskfiles to launch wails3

[warpfork]

Is your feature request related to a problem? Please describe.

Currently, wails documentation and convention tells users to put the wails/wails3 tool on their $PATH.

There's another way. The go tool command can now be used to run commands using versions from the nearest go module and its sum file. This offers greater setup simplicity, gives version management "for free", and makes it much easier to work on multiple different Wails projects (potentially at different versions) at once in a reliable and carefree way.

Describe the solution you'd like

Setting up to be able to use go tool is a one-line addition to the go.mod file for a project:

tool github.com/wailsapp/wails/v3/cmd/wails3

(or, tool github.com/wailsapp/wails/v2/cmd/wails for v2.)

Then, everywhere that uses wails3 as a command can instead be go tool wails3, and everything works exactly the same... except you're definitely getting the version of the tool that matches with everything else in your go module, and you don't need any additional setup steps to put it onto your $PATH.

In Wails v2, this is mostly a user's concern -- they just run go tool wails dev, go tool wails build, etc etc, in their shell. (Or wrap a makefile around it to shorten things and offer reminders; potato potato.)

In Wails v3, the tooling invokes itself quite a bit, so this isn't just a matter of how the user holds it. The Taskfile system invokes wails3 in several places, and updating all those to go tool wails3 is necessary to get the desired of result of one-version-across-the-project. Doing this in a project after it's been templated is possible but a bit of a slog. All of the changes are in Taskfile.yml files or the build/config.yml file (but there's a lot of them; I think 17).

I propose in Wails v3, the new project template (e.g. v3/internal/commands/build_assets/Taskfile.tmpl.yml and friends) could do this go tool wails3 pattern out-of-box.

Describe alternatives you've considered

I've been doing this in my Wails projects for a while now and it's great. I'm not really aware of any downsides at all.

Additional context

No response

[leaanthony]

Not a bad idea... You'd still need the initial wails3 binary to create the project though. Would people now need to update go.mod to update CLI version instead of just installing the new one?

I'll be honest, I'd rather a more limited, but frictionless default than to introduce complexity for flexibility. Of course, anyone could choose to update their taskfiles to do this.

[warpfork]

Having a good first time onboarding story is important, but IMO I don't think the weighting should go all-in on that (if that compromise is unavoidable at all, which I'll also debate). My thinking would be that initial project templating happens once, and maintenance (and potentially switching between projects using different versions of wails) happens forever. Having the latter one keep working is a lot more important to me if I'm going to finish and maintain (multiple) projects in wails, rather than just start them.

Yes, users would now bump the go.mod version instead of installing a new CLI version. However, to me, that doesn't seem like a large hurdle? I'd actually call it easier than making mutations to my bigger-picture $PATH. And it's certainly significantly simpler than dealing with whatever potential challenges might arise when there's a drift in versions between the wails3 tool in $PATH and what the code in the repo was expecting. (I realize there's an aim to not have breaking changes there, but... while that's also a fine goal, consistent tool versioning is still one fewer potential problem in a complex system.)

Initial project templating could still happen through some kind of go run command, afaik. Although also I imagine just having a template repo to clone (without any significant additional processing) would also probably work without any tool step at all. (The taskfiles seem to use interpolations thoroughly enough that just changing some default fields like APP_NAME from whatever placeholder they have in a template repo should be low friction.) (YMMV, but honestly, personally, I've always preferred template repos to template tools by a large margin anyway: they have much less opportunity for surprises.)