Is your feature request related to a problem?
The generated CUE is correct but not particularly readable or
idiomatic. If the goal is for humans to work with the converted
output — understanding it, modifying it, or using it as a starting
point — readability matters as much as correctness.
Proposed solution
This is a tracking issue for readability improvements. Some known
areas:
Helper boilerplate. Utility definitions like _nonzero,
_semverCompare, _trunc, _dig, _omit, and _typeof are
emitted inline with substantial boilerplate. Call sites like
(_nonzero & {#arg: expr}).out are verbose and obscure the intent.
These are candidates for CUE standard library builtins; once those
exist the generated code becomes much cleaner. In the meantime,
consider whether the call-site syntax can be simplified.
Condition expressions. if (_nonzero & {#arg: #values.enabled}).out
is a roundabout way of saying "if this value is truthy". Idiomatic
CUE would express this more directly.
Schema declarations. #values: { name!: bool | number | string | null ... }
uses the broadest possible scalar type. More precise type inference
(string vs int vs bool) from how values are used in templates would
produce tighter, more useful schemas.
Formatting and structure. The generated CUE should follow
idiomatic CUE style — field ordering, grouping, comment placement,
and whitespace — so it reads naturally to someone familiar with CUE.
General idiom. Patterns that are correct but unnatural in CUE
should be identified and replaced with more idiomatic equivalents
as the converter matures.
Additional context
This issue collects readability concerns in one place. Individual
improvements can reference it.
Is your feature request related to a problem?
The generated CUE is correct but not particularly readable or
idiomatic. If the goal is for humans to work with the converted
output — understanding it, modifying it, or using it as a starting
point — readability matters as much as correctness.
Proposed solution
This is a tracking issue for readability improvements. Some known
areas:
Helper boilerplate. Utility definitions like
_nonzero,_semverCompare,_trunc,_dig,_omit, and_typeofareemitted inline with substantial boilerplate. Call sites like
(_nonzero & {#arg: expr}).outare verbose and obscure the intent.These are candidates for CUE standard library builtins; once those
exist the generated code becomes much cleaner. In the meantime,
consider whether the call-site syntax can be simplified.
Condition expressions.
if (_nonzero & {#arg: #values.enabled}).outis a roundabout way of saying "if this value is truthy". Idiomatic
CUE would express this more directly.
Schema declarations.
#values: { name!: bool | number | string | null ... }uses the broadest possible scalar type. More precise type inference
(string vs int vs bool) from how values are used in templates would
produce tighter, more useful schemas.
Formatting and structure. The generated CUE should follow
idiomatic CUE style — field ordering, grouping, comment placement,
and whitespace — so it reads naturally to someone familiar with CUE.
General idiom. Patterns that are correct but unnatural in CUE
should be identified and replaced with more idiomatic equivalents
as the converter matures.
Additional context
This issue collects readability concerns in one place. Individual
improvements can reference it.