cue lint command

[NoamTD]

Is your feature request related to a problem? Please describe.

I have noticed a few cases in which users write technically valid cue that doesn't actually work - it's valid and works as expected based on the cue spec, but it's most likely a user mistake or doesn't behave the way the user intended.

For example, the following are very common mistakes and very often unintended:

// intended to reference some global field called x, but the global field is "shadowed"
x: x

// less experienced users might expect that a's fields must start with "foo" - but this is not the case
#Constraint: =~"^foo"
a: [#Constraint]: _
a: bar: {}

Describe the solution you'd like
A cue lint command that will allow cases like this to be caught early

Describe alternatives you've considered
I think the required functionality for such a command is freely available in the public api, so this doesn't necessarily need to be part of the cue command, or even the cue project.

[mvdan]

You're completely right about the first one; see #466. Although note that it mentions a "warning" and later on a cue vet rule.

The second one is perhaps a pitfall too, but what if a user really intended that behavior - what should they write instead?

I think it's fine to leave this issue open in terms of "do we want a lint command, and if so, what should be in it?". My personal opinion is that any bits of CUE which are clearly wrong (like a: a) or which can be written in a significantly better/clearer way should either be evaluator errors or cue vet errors. Basically, pushing users towards fixing all of them, whereas a warning tends to be a more vague "there may or may not be an issue here" that users have to make a choice on, and many users then simply ignore. This is why Go tends to avoid warnings or imprecise linters in nearly all cases.

And, if the linter were to be precise, and it should be obeyed... Then one could argue we already have such a command, cue vet :)

[mvdan]

I'm going to close this for now with the reasoning above. Happy to reopen or to discuss this further in a new issue, discussion, or Slack/Discord thread if you have more ideas.

[NoamTD]

forgot to answer, I wasn't aware of #466 and I agree with best practices being built in to the language - if I come up with better examples I will approach them as separate issues, instead of the need for a general linting ability