provide help for build command about xk6 HOT 6 OPEN

@na--

Re: cmd/xk6, I don't see the benefits of moving to main.go, and think the current structure is a better practice for CLI tools, so would rather leave it as is.

Also if you move main.go into root folder, then you will unable to publish xk6 as library, because of main.go should be in main package and as I know no way to put go files in same directory with other package declaration...

from xk6.

Also, do we really need the cmd/xk6/ package? That pattern might make sense for projects that can produce multiple binaries, but xk6 will likely never be such a project, so why not have our main package in the root folder?

from xk6.

Hey, sorry about the late reply :)

The tricky thing about this is that xk6 is meant to be run from an extension project directory and to just passthrough whatever arguments it receives (except build) directly to k6. So xk6 --help actually runs k6 --help and xk6 version runs k6 version.

This is meant to serve quick dev iterations where the arguments are exactly the same as what k6 receives, and I think that makes sense.

The alternative would be to shadow even more possible k6 commands, or to use the somewhat standard convention of -- to signify that arguments before -- are meant for xk6 and arguments after are meant to be passed to the child command, but that kind of defeats the quick iteration benefits and would break the current UI.

Or we could detect the go list -m failure to assume that we're not in a Go module project directory and interpret the arguments for xk6, but that seems hacky to me.

WDYT?

Re: cmd/xk6, I don't see the benefits of moving to main.go, and think the current structure is a better practice for CLI tools, so would rather leave it as is.

from xk6.

@imiric

Or we could detect the go list -m failure to assume that we're not in a Go module project directory and interpret the arguments for xk6, but that seems hacky to me.

WDYT?

Let create a sub-command pattern in xk6. Put current build functionallity under "build" subcommand and pass all other subcommand to k6. In this way you can use usual flags parsing under "build" sub-command (like xk6 build --help)

from xk6.

Yeah, improving xk6 build makes sense, xk6 build --help should work as expected at least. Getting the xk6 version with xk6 build --version would be confusing though, and eventually we'll probably need other subcommands. These ambiguities when one command passes arguments to another are usually handled with an -- argument, but that would likely break existing usage.

We'll consider prioritizing this issue soon, and in the meantime PRs are welcome. :)

from xk6.

This was brought up again recently by @andrewslotin, and it might be good to clarify: xk6 --help and xk6 version do work within a directory of a k6 extension. But maybe surprisingly so, since in that case the implicit binary building will succeed and that flag and argument will be passed to k6 instead. Any args passed to xk6 that should be interpreted by xk6 will invariably need to shadow k6 args. Currently this is only the case with xk6 build, but if k6 one day adds such an argument then we'll need to figure something else out.

So there's that discussion of how we want the xk6 CLI to work, and I think there are valid arguments to be made on both sides.

As for the case when xk6 is run outside of a k6 extension directory, currently it prints something similar to the error in the issue description:

$ xk6
go: cannot match "all": go.mod file not found in current directory or any parent directory; see 'go help modules'
2022/07/13 16:41:12 [ERROR] exec [go list -mod=readonly -m -f={{if .Replace}}{{.Path}} => {{.Replace}}{{end}} all]: exit status 1:

This is undoubtedly cryptic to even users familiar with Go, so we could possibly improve that scenario, and always default to building a vanilla k6 if a go.mod is not found in the CWD. That way we'll at least show whatever error k6 outputs, and things like xk6 --help will work, though they'll actually show k6 --help. WDYT?

from xk6.