Consider moving to `task` for builds

[bradleypeabody]

Recent changes to the Go tooling have made using go run somescript.go for build tooling increasingly difficult. Between the module system which expects a go.mod to be present and match the imports even for such standalone tools, and the fact that dependencies require a go get before use (instead of being downloaded automatically) - these changes while they exist for good reason, basically broke what Vugu has been recommending for builds. There are workarounds using the GO111MODULE option and others, but they are not particularly obvious or simple.

What we need is essentially very simple. Something akin to a Makefile that runs the same on Windows/Linux/Mac and can be installed with a single command and then executed with another single command is all most projects typically need.

task (https://taskfile.dev) seems to be a good fit. It is also written in Go.

We'll need some good examples and documentation of the recommended approach, but so far I think this would alleviate a good deal of the build pain that is developed around Vugu with recent Go releases.

And also just to be clear, while the commands we need to run are typically simple - vugugen with some arguments and then go build with some arguments, it's still more than we want developers to have to remember. A consistent build by just typing task and then a consistent local development run with something like task run is what we're after.

[gedw99]

https://github.com/mdouchement/fichenn/blob/master/Taskfile.yml seems like a good example

[owenwaller]

For completeness there is also Mage

But I want to suggest a different approach, especially for production.

I think we need to document what you need to do to build a vugu application using the standard go tools, so calling go generate or go build with the GOOS=js and GOARCH=wasm set.

If this is clearly documented then teams that need the information, like mine and we are using Makefiles, will know what to do.

I have no objection to supporting a 3rd party build system or providing Vugu tooling to help e.g. vugugen etc. if that helps get folks started, or if it is what the community asks for.

Also, what I don't want is to have a to have a full Go toolchain on any of my production servers. So things like this:

https://github.com/vugu/vugu/blob/885d6b14f1fe3b110fcf301e85e09025bd927009/simplehttp/simple-handler.go#L238-L241

In the simplerhttp package, which is the current recommended approach for distribution, I don't think will fly for us.

We just need a way to produce the WASM artefact, and then we can serve it however we want. I've no objection to using a Go HTTP server for this, but this leaves open the possibility of nginx, or apache etc.