cmd/cue: error reporting should have a cue/json/yaml output option

[eventgraph]

Is your feature request related to a problem? Please describe. The cli is great at telling you what needs to change, however the format isn't conducive to piping into other tooling (jq for example). Since cue is a superset of JSON it makes sense the output would also match that format.

Describe the solution you'd like It makes sense that there is an error.cue that errors would output to. This would allow piping to json/yaml/openapi for things like validation errors.

Instead of

Value.nums.0: invalid value -1 (out of bound >0):
    ./music.cue:9:18
    ./music.cue:23:9

Not really sure of the format but something like

errors: #Errors & [{
    path:    "Value.nums.0"
    value:   -1
    message: "out of bound >0"
    locations: {
        "./music.cue": [{
            line:   9
            column: 18
        }, {
            line:   23
            column: 9
        }]
    }
}]

Describe alternatives you've considered Leave as is, I'm new to Cue so I don't the reasoning for decisions and probably missing vital context. The current format is nice and terse.

Additional context

Dogfooding in general is good for everyone, the default behavior was surprising in that it didn't match the style used in inputs.

[mvdan]

Worth noting that one option is to use the Go APIs rather than the command line, as the errors are already structured in the Go API: https://pkg.go.dev/cuelang.org/go/cue/errors

If you do need to use the command line cue tool, a somewhat similar solution exists in the Go world, where commands like go test -json or go list -json produce their entire output as a newline-separated stream of JSON values. We could consider a similar design if we want any parts of the CLI to be more computer-friendly.

[eventgraph]

@mvdan 💯 what I was thinking but more concise. I plan to use cue in Go so this doesn't directly effect me but seems like logical for better integrations outside of Go.

[mvdan]

Integrations with other languages are often made with the command line tool today, but that doesn't need to be the case in the future, either :) That said, I certainly don't object to -json flags if people would find them useful.

[myitcv]

Marking as "needs planning" for now. We will revisit all feature requests after the current "garden" of bugs and other issues. Thanks for raising, @eventgraph!