djLint check mode cannot see single_attribute_per_line, so lint-templates passes on unformatted templates

[fsecada01]

Surfaced by #55 / PR #60, which patched one instance of it without closing the hole.

The problem

just lint-templates reports 0 errors on templates that djlint --reformat immediately rewrites.

single_attribute_per_line is a reformat-only rule. djLint's check mode does not evaluate it, so the gate is structurally blind to the one formatting rule this repo actually cares about. Concretely: the 12 box/prose templates shipped in #54 passed just lint-templates and passed prek, and prek run --all-files on the very next branch restyled all 12 of them.

That means "the template lint passed" is not evidence a template is formatted, and every contributor's hook run dirties files they did not touch until someone happens to commit the formatter's output.

Why the current fix is a patch

PR #60 commits djlint's output for those 12 files. That resolves this instance and does nothing about the next new template. The repo's own rule — replace the mechanism, don't patch it — says the gate should be able to fail, and right now it cannot.

Options

1. Check-mode equivalent. Run djlint --reformat against a scratch copy of both trees and fail on any diff. This is what ruff format --check does for Python and it makes the existing just lint-templates honest. Cost: a second pass over 231 files, and the scratch-copy plumbing in the justfile.
2. Make the prek hook fail on modification rather than silently reformatting and reporting Passed. Cheapest, catches it at commit time, but only for files in that commit — a hook that reformats and passes is the proximate reason this went unnoticed.
3. Drop single_attribute_per_line if the layout it produces is not worth enforcing. Also a legitimate answer; it is a preference, not a correctness rule.

1 and 2 compose and are probably both wanted — 2 for the fast local signal, 1 so CI cannot be greener than a fresh --reformat.

The constraint any fix must respect

Whatever lands must not let djLint touch a class="…" value. single_attribute_per_line is layout inside the opening tag only; whitespace added inside a class value changes the rendered bytes and breaks the substring assertions the primitives parity tests depend on. That constraint is already documented in CLAUDE.md and is the reason this rule needs a guard rather than a blanket "just run the formatter."

Acceptance criteria

• A template that djlint --reformat would rewrite fails the gate — just lint-templates, CI, or both.
• Proven non-vacuous: deliberately un-format one template, watch the gate go red, restore it. A check that has never been seen to fail is not a check.
• Both trees covered (cotton with --profile=django, jinja with --profile=jinja --extension=jinja) — the drift appeared in both.
• CLAUDE.md's djLint section updated to say that check mode does not see reformat-only rules, since that is the non-obvious fact behind the whole issue.

[fsecada01]

Closing as not worth fixing, same call as #62 and for a similar reason. Recording it so it does not get re-filed the next time prek run --all-files dirties a template nobody touched.

The mechanism is real and I am not walking it back: single_attribute_per_line is a reformat-only rule, djLint's check mode does not evaluate it, and just lint-templates therefore reports 0 errors on files that --reformat immediately rewrites. That is how #54's 12 new box/prose templates passed the gate and then got restyled on the very next branch.

What that costs, concretely: someone occasionally commits the formatter's output for files they did not edit. Nothing renders wrong, no test is weakened, and the rendered bytes are unaffected — the rule is layout inside the opening tag only, never inside a class="…" value, which is the one thing that would break the parity tests' substring assertions.

What the fix costs: a second full djLint pass over 231 files in the gate, plus scratch-copy plumbing in the justfile to diff --reformat output without mutating the tree, maintained permanently.

For a repo with one contributor, that trade is not worth making. The cheap remedy — commit djLint's output when it drifts, as PR #59 did — costs one commit on the rare occasion it comes up.

Worth revisiting if either of these changes:

• More than one regular contributor. The annoyance scales with the number of people whose working tree gets dirtied by a hook run they did not cause, and a dirty tree that is "normal" trains people to ignore git status, which is the actual risk here rather than the formatting itself.
• single_attribute_per_line starts mattering for correctness rather than taste. Right now it is a layout preference. If a rule is ever enabled whose output changes rendered markup, check-mode blindness stops being cosmetic.

The third option in this issue — dropping single_attribute_per_line — stays available and would also close the gap, by removing the unenforceable rule rather than building machinery to enforce it. Not doing that either, since the layout it produces is the repo's house style and the templates are already formatted to it.