Daniel Martí

@myitcv and I are in agreement that, at minimum, for v0.12 we need to better document the existing behavior in `cue vet -h` and cuelang.org content.

Indeed, I think this is the reverse of the bug I fixed at https://review.gerrithub.io/c/cue-lang/cue/+/1198874. I fixed the JSON decoder so that it rejects zero or many values, but I didn't...

Thanks for thinking through some options in https://github.com/cue-lang/cue/issues/3288#issuecomment-2298727114. I don't think breaking `cue export` with multiple packages is an option; `cue export ./...` is a fairly common pattern, so that...

Another option would be to change the default output format for `cue export`, but that would in itself be a breaking change, and we don't have good options: * YAML...

We indeed want to move towards making staticcheck happy. We already enforce vet, but we don't enforce staticcheck yet, due to all the deprecation warnings (https://github.com/cue-lang/cue/issues/2480). We are moving in...

Yes we do intend to enforce staticcheck in CI - there isn't a tracking issue for it as https://github.com/cue-lang/cue/issues/2480 is a fairly big blocker for that. Although we could start...

Sure. Let's use it just to enforce a subset of staticcheck (minus SA1019 for the deprecation warnings, as that's https://github.com/cue-lang/cue/issues/2480, and minus third_party and golangorgx). I don't think it's worthwhile...

`internal/third_party` is now gone since https://review.gerrithub.io/c/cue-lang/cue/+/1199541, so that's one chunk we no longer need to worry about.

Sounds good. Just give me five minutes as I'm about to merge some I did this morning.

> Even filtering out `third_party`, `golangorgx` and `deprecated`, there are around 80 suggestions (52 of which are `unused`). With `third_party` now gone, and after chipping away at some more of...