You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The rustywind hook in .pre-commit-config.yaml is configured with rustywind@latest (unpinned). As of 0.26.0 (released 2026-07-21), rustywind re-sorts Tailwind CSS classes differently than 0.24.3, so the hook wants to rewrite ~183 HTML templates (pure class reordering, no content changes) and would fail the lint job.
Evidence
npm latest for rustywind currently resolves to 0.26.0 (released 2026-07-21); the previous stable was 0.24.3 (2025-08-08), with 0.25.x on 2026-07-06/08.
Running pre-commit run rustywind --all-files against current main (3050cc60) with @latest → 0.26.0 modifies 183 files.
This is currently masked by the GitHub Actions cache: hypha-ci.yml caches ~/.cache/pre-commit with key pre-commit-3|${{ env.pythonLocation }}|${{ hashFiles('.pre-commit-config.yaml') }}. Since .pre-commit-config.yaml and the pre-commit-3 prefix (added in Replace pre-commit/action that uses outdated node version with direct install and call of pre-commit #4849, 2026-05-21) haven't changed since the env was built against 0.24.3, every run is a cache hit and keeps using 0.24.3 — so lint passes today.
The next time .pre-commit-config.yaml changes (e.g. a routine hook-version bump), the cache key busts, pre-commit installs rustywind@latest → 0.26.0, and lint fails on ~183 templates.
A downstream fork without the same caching already hit this: their CI installs pre-commit hooks fresh each run, so @latest resolved to 0.26.0 and the lint job went red on the same code that passed ~5 weeks earlier with 0.24.3 — confirming the tool changed, not the code.
Proposed fix
Pin the version explicitly instead of @latest, and absorb the new sort order deliberately:
additional_dependencies:
- rustywind@0.24.3 # no template changes; bump + reformat later
Or pin to 0.26.0 and reformat the ~183 templates in a dedicated commit. Either way, removing @latest prevents future silent drift failures.
Reproduce
pre-commit clean # drop the cached env
git clean -fdx # or just remove the rustywind env
pre-commit run rustywind --all-files # installs 0.26.0, rewrites 183 files, fails
rustywind --version # 0.26.0
Reported by GLM-5.2 (prompted by Jesse Bickel), on behalf of a downstream fork.
Summary
The
rustywindhook in.pre-commit-config.yamlis configured withrustywind@latest(unpinned). As of0.26.0(released 2026-07-21), rustywind re-sorts Tailwind CSS classes differently than0.24.3, so the hook wants to rewrite ~183 HTML templates (pure class reordering, no content changes) and would fail thelintjob.Evidence
latestforrustywindcurrently resolves to 0.26.0 (released 2026-07-21); the previous stable was0.24.3(2025-08-08), with0.25.xon 2026-07-06/08.pre-commit run rustywind --all-filesagainst currentmain(3050cc60) with@latest→ 0.26.0 modifies 183 files.hypha-ci.ymlcaches~/.cache/pre-commitwith keypre-commit-3|${{ env.pythonLocation }}|${{ hashFiles('.pre-commit-config.yaml') }}. Since.pre-commit-config.yamland thepre-commit-3prefix (added in Replace pre-commit/action that uses outdated node version with direct install and call of pre-commit #4849, 2026-05-21) haven't changed since the env was built against 0.24.3, every run is a cache hit and keeps using 0.24.3 — solintpasses today.The next time
.pre-commit-config.yamlchanges (e.g. a routine hook-version bump), the cache key busts, pre-commit installsrustywind@latest→ 0.26.0, andlintfails on ~183 templates.A downstream fork without the same caching already hit this: their CI installs pre-commit hooks fresh each run, so
@latestresolved to 0.26.0 and thelintjob went red on the same code that passed ~5 weeks earlier with 0.24.3 — confirming the tool changed, not the code.Proposed fix
Pin the version explicitly instead of
@latest, and absorb the new sort order deliberately:Or pin to
0.26.0and reformat the ~183 templates in a dedicated commit. Either way, removing@latestprevents future silent drift failures.Reproduce
Reported by GLM-5.2 (prompted by Jesse Bickel), on behalf of a downstream fork.