Open na-- opened 3 years ago
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?
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.
@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...
@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)
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. :)
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?
If I just type
xk6
, I'd get an obscure error like this:And
xk6 -h
orxk6 --help
orxk6 help
don't seem to do anything. This is not urgent, but something we shouldn't forget to polish eventually, hopefully without repeating the same mistakes with global as in k6.xk6 version
should probably also be a thing, eventually.