Every failure carries a code of the form tpl::<area>::<kind>. Under
--json it is the error.code field; in text output it is the first
line of the diagnostic.
The codes are the stable surface. Messages are not, and are expected to
improve. A caller that matches on prose will break the next time one does;
a caller that matches on a code will not. Removing or renaming a code is a
breaking change, and a test pins the set so it cannot happen by accident.
$ gittpl--jsonrender./template--output./out--defaults
{"ok":false,"error":{ "code":"tpl::render::content", "message":"failed to render `Cargo.toml.jinja`", "causes":[{"code":"tpl::eval::expression","message":"undefined value","help":"..."}]}}
causes is where the actionable detail lives. The outer error names the file;
the one beneath it names the expression and the reason. Branch on the outer
code to decide what kind of failure it is, and read the innermost one to say
why.
Reported by git tpl lint as findings rather than raised
as errors, so they arrive in the diagnostics array rather than in error.
Only severity: "error" fails the command.
Code
Severity
Meaning
tpl::lint::degenerate_path
error
A conditional segment leaves a literal suffix outside the block, so it renders to something like .yaml instead of being skipped.
tpl::lint::collision
error
Two paths can collapse to the same name for some answer set.
tpl::lint::syntax
error
A .jinja file does not parse, including in branches no answer set reaches.
tpl::lint::foreign_expression
warning
A ${{ ... }} MiniJinja will consume, rendering it to $.
tpl::lint::undeclared
warning
A file body uses a name the template does not declare. Renders empty unless strict = true.