0.11.35 — the guard that stopped failing

The header broke three times, and each time it was a person on a phone who noticed, not a test. Hence a guard that renders the page at eight viewport widths and checks that the site name, the navigation and the icons do not overlap. A review found it had been ending in a missing-package error for several releases, and nobody had noticed, because nobody was running it.

The obvious fix would have been the wrong one. Adding playwright to the dependencies means downloading a browser — a hundred and fifty megabytes or so — into every fresh working environment, for a test run once every few releases. A test that renders a page belongs to the continuous integration run, where the browser installs once and is cached.

Run without the package, the script now skips with a message and exits successfully instead of dying. This is not hiding an error: a guard that always fails teaches a team that guard failures are to be ignored — and then it stops working on the day it actually catches something.

A second layer arrives for use before a commit, cheap and local. All three header failures shared a cause in the layout classes: the icon group without the class that prevents shrinking pushed the row wider than the screen, and the name without permission to shrink pushed the icons off it. Checking statically that those classes are in place costs milliseconds and catches exactly that kind of regression. Rendering stays as the sieve for what static checking cannot see.

The division generalises beyond this one case. A guard must be either cheap enough to run constantly, or placed where it runs by itself. A guard that is expensive and run by hand is not a guard — it is a document about good intentions.