Hwaro::Content::Hooks::ImageVariantStamps
What each generated image variant was cut from.
Warm builds (--cache, every serve rebuild) reuse a variant that
already sits in the output directory. File mtimes alone cannot say
whether that is still right: a source swapped for an older-mtime copy
(rsync -a, tar -x, a restored revision) passes an "is the variant
newer than the source" test, and a change to the encode settings
(quality, the LQIP knobs) leaves every file looking fresh. So each
variant is stamped with a fingerprint of its inputs — the source's
exact mtime and size plus the encode settings — and is reused only
while the stamp equals the one the current build would produce. No
stamp (first build after an upgrade, .hwaro/ deleted) means "not
proven fresh", so the variant is regenerated once; the bytes it
regenerates are the same a cold build writes.
The record is an append-only JSON-lines log in .hwaro/, next to the
other workspace state and never published: recording is O(1) per
variant (render-time fill/crop variants are made one at a time), the
last line for a variant wins, and a log that has outgrown its live
entries is rewritten when it is loaded.
Constants
Bump when the bytes a variant is encoded to change without any input changing (a WebP/JPEG/PNG encoder or resampler fix): every stamp then mismatches once and warm builds re-encode, so they keep writing what a cold build writes. Same rule as OgImage's RENDER_REVISION.
Instance methods
Fingerprint of source plus settings and the encoder revision;
nil when it cannot be statted (nothing to reuse then).
Was dest last written from exactly fingerprint?