mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
Reece Browne
b35329c8f5
## What Two related bugs found while looking at why #7187's a11y check behaves differently on CI than locally. ### 21 stories were never being scanned on CI The scan tasks only depended on `install`, not `prepare`. On a fresh checkout that means the generated icon set (`editor/src/assets/material-symbols-icons.json`, gitignored) doesn't exist, so every story that reaches `LocalIcon` fails to import: ``` Failed to resolve import "../../../assets/material-symbols-icons.json" from "editor/src/core/components/shared/LocalIcon.tsx" ``` On CI that was four story files / 21 stories, every run. It works locally only because our trees already have the file from a previous build. The scan tasks now depend on `prepare`, like the `build:*` tasks do. ### The gate reported those runs as clean Worse than the missing stories: a file that fails to import produces a **failed suite with no assertions**. Every check in `a11y-check.mjs` reads assertions, so the file satisfied the manifest, contributed nothing to compare, and the run printed `✓ no a11y regressions`. An assertion-less failed suite now fails the gate and points at the scan log for the underlying resolve error. `--record` refuses in the same situation, so a baseline can't be written that quietly drops those stories. Also switched the affected-story emptiness test to single quotes, since that list now carries its own per-path quoting (it was producing `[ -z ""a" "b"" ]`). ## Testing - Deleted the generated asset to reproduce a fresh checkout: the gate **fails** with the file named and the cause explained, where before it printed `✓ no a11y regressions` and exited 0. - With the `prepare` dependency the task regenerates the asset itself and the previously-invisible files scan: 21 stories, 35 story-rule pairs, all already baselined.