mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-02 21:03:34 +03:00
Reece Browne
22ec0947c9
## What Gets most of the app's components into Storybook and adds a scan that runs every story in a real browser, so we have a base to build accessibility testing on next. - **~380 new stories**, taking story files from 144 to 526. Components with a story: | Layer | Before | After | |---|---|---| | core | 41 / 309 (13%) | **183 / 309 (59%)** | | portal | 91 / 161 (57%) | **127 / 161 (79%)** | | proprietary | 1 / 105 (1%) | **39 / 105 (37%)** | | cloud / desktop / saas / portal-saas / prototypes | 0 / 84 | 0 / 84 (unchanged) | | **Total** | **133 / 659 (20%)** | **349 / 659 (53%)** | Both columns are counted the same way — every `.tsx` exporting a component, so the denominator includes things that aren't really visual units (contexts, providers, barrels). Excluding those it's 22% → 58%. Either way it's reproducible from the tree rather than a number you have to take on trust. - **Scan harness** — the Storybook Vitest addon runs each story in headless Chromium as a **render/smoke check** (a story must mount without throwing). New task: `task frontend:storybook:test` (pass a filter, e.g. `-- Button`). Separate Vitest config so it doesn't touch the existing jsdom unit tests. ## Scope - **Stories and Storybook config only, with one exception:** a one-line fix to `ProviderCard`, which re-rendered forever whenever its optional `settings` prop was omitted. Called out because it's the only component source change here. - The preview gains a `QueryClientProvider` (the portal app has one, so stories reaching a query hook threw without it), and the scan task now installs the browser it drives. - **a11y is report-only** and **nothing runs the scan in CI yet** — enforcing a11y and wiring it into CI is the follow-up, #7086. - Components that can't render as an isolated unit are **not** included: anything needing the full editor runtime (ToolWorkflow / FileManager / AppConfig / a live PDF engine) or that's headless (providers, gates, API bridges, config factories). Stories that only rendered by mounting the whole `AppProviders` tree were dropped for the same reason — that isn't isolation, and the tree's ErrorBoundary swallowed render failures so those stories could never fail. A few that need assets the headless browser can't serve are tagged `!test`, so they still show in the UI but sit out the scan. ## Testing Typecheck (all build variants), ESLint, Prettier and the unit suite pass. Every story in the scanned set mounts without throwing. ## Notes for reviewers - Stories use the `@app`/`@core`/`@portal`/`@proprietary` aliases (no deep relative imports) and mock data-fetching components with MSW. - Running the full suite in one go can flake on the Vite dep-optimizer; scan in small batches (or by filter) for a stable local run.
8 lines
529 B
TypeScript
8 lines
529 B
TypeScript
// Root Vitest config so the Storybook addon-vitest Testing UI (and a bare
|
|
// `vitest` run from frontend/) discovers the Storybook browser-test project.
|
|
// The project definition lives in .storybook/vitest.config.ts; this re-exports
|
|
// it from the conventional root location. The editor unit tests are separate
|
|
// (editor/vitest.config.ts, run with `vitest --root editor`).
|
|
// eslint-disable-next-line no-restricted-imports -- config re-export; no @-alias covers .storybook/
|
|
export { default } from "./.storybook/vitest.config";
|