Found while writing negative goldens for #446 - the new parse/errors and eval/errors_runtime fixtures pin these messages as-is, so improving them means updating goldens (by design: the fixtures are regression anchors for message quality).
-
Parser messages leak internal token names, redundantly: expected RBrace in type body (expected RBrace, got EOF) and expected Colon in field type annotation. Users should see } / : once, not Go token identifiers twice.
-
The classic : vs = mixup gets no nudge: name: "web" inside a struct literal yields only expected expression, got Colon. This is THE most common syntax confusion for anyone coming from JSON/YAML - it deserves a targeted hint ("struct literal fields use =, e.g. name = "web"") per the core error-UX principle.
-
for-in requires a list does not say what type it got and has no hint.
Error messages are self-documenting and guiding - a user should reach a valid config by following them alone. These three fall short of that bar.
Found while writing negative goldens for #446 - the new parse/errors and eval/errors_runtime fixtures pin these messages as-is, so improving them means updating goldens (by design: the fixtures are regression anchors for message quality).
Parser messages leak internal token names, redundantly:
expected RBrace in type body (expected RBrace, got EOF)andexpected Colon in field type annotation. Users should see}/:once, not Go token identifiers twice.The classic
:vs=mixup gets no nudge:name: "web"inside a struct literal yields onlyexpected expression, got Colon. This is THE most common syntax confusion for anyone coming from JSON/YAML - it deserves a targeted hint ("struct literal fields use =, e.g. name = "web"") per the core error-UX principle.for-in requires a listdoes not say what type it got and has no hint.Error messages are self-documenting and guiding - a user should reach a valid config by following them alone. These three fall short of that bar.