Introduces --json flag for k6 version sub-command

[olegbespalov]

What?

This PR introduces the new --json flag for k6 version sub-command, which switches the output format to a JSON.

Here are some examples:

Basic

./k6 version --json | jq
{
  "commit": "ec1f601e4f",
  "commit_dirty": true,
  "go_arch": "amd64",
  "go_os": "linux",
  "go_version": "go1.23.2",
  "version": "v0.55.0"
}

./k6 version
k6 v0.55.0 (commit/ec1f601e4f-dirty, go1.23.2, linux/amd64)

./k6 --version
k6 v0.55.0 (commit/ec1f601e4f-dirty, go1.23.2, linux/amd64)

With extensions:

./k6 version --json | jq
{
  "extensions": [
    {
      "imports": [
        "k6/x/sql"
      ],
      "module": "github.com/grafana/xk6-sql",
      "version": "v0.0.1"
    }
  ],
  "go_arch": "amd64",
  "go_os": "linux",
  "go_version": "go1.23.2",
  "version": "v0.55.0"
}

./k6 --version
k6 v0.55.0 (go1.23.2, linux/amd64)
Extensions:
  github.com/grafana/xk6-sql v0.0.1, k6/x/sql [js]

./k6 version
k6 v0.55.0 (go1.23.2, linux/amd64)
Extensions:
  github.com/grafana/xk6-sql v0.0.1, k6/x/sql [js]

Why?

Having the ability to produce JSON structured output is essential if k6 used as part of some automation.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make tests) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

[szkiba]

I suggest using the extension registry terminology.

First of all, there is no such thing as a JavaScript or Output extension. An extension can register one or more import paths and one or more output names. That is why the registry has array properties of type "imports" and "outputs" for extensions.
Also, the extension does not have a name. There is a go module path, and there is (if there is one) a repository for the extension, and the repository has an owner and a name. However, the repository name is not unique. What is unique is the go module path.

I suggest taking the following properties from the registry:

• module
• imports
• outputs

I also suggest deleting the following properties:

• name
• type

[olegbespalov]

I suggest taking the following properties from the registry:

@szkiba do you mean to perform a network call to registry? 🤔

[szkiba]

I suggest taking the following properties from the registry:

@szkiba do you mean to perform a network call to registry? 🤔

No, sorry. I mean use that property names and values

[olegbespalov]

@szkiba wouldn't be hard for you modifying the output to reflect your request, in general I do agree that it make sense to follow registry terminology 🤝

"extensions": [
    {
      "name": "k6/x/sql",
      "path": "github.com/grafana/xk6-sql",
      "type": "js",
      "version": "v0.0.1"
    }
  ]

[szkiba]

"extensions": [
    {
      "module": "github.com/grafana/xk6-sql",
      "imports": ["k6/x/sql"]
      "version": "v0.0.1"
    }
  ]

like this

[mstoykov]

LGTM in general, but would really prefer if we keep making lib/consts not actually about constants and especialyl as this is only used in cmd it seems like a good idea to just move it there and unexport it

[oleiade]

This looks really good, great work! 🚀