chore(storybook): drop the redundant setProjectAnnotations setup file - #1968
chore(storybook): drop the redundant setProjectAnnotations setup file#1968cliffhall wants to merge 2 commits into
Conversation
Since Storybook 10.3, @storybook/addon-vitest provisions the preview annotations itself — and *skips* doing so when it finds a setup file calling setProjectAnnotations. So .storybook/vitest.setup.ts was not merely redundant, it was actively opting the project out of the automatic path, which the addon printed a notice about on every run. Remove the file and the `setupFiles` entry from the `storybook` vitest project. A green suite doesn't prove the automatic provisioning works: without the preview annotations, stories would render outside MantineProvider and without App.css, and would very likely still pass. Add src/test/PreviewAnnotations.stories.tsx, which asserts from a play function that the Mantine theme variables and the App.css tokens are actually present in the rendered document, so an unthemed render fails loudly. Verified by emptying `decorators` in preview.tsx and confirming the story goes red. The a11y addon's axe runner can't be introspected from a play function, so it was checked out-of-band: a story with a real violation turned the suite red with the setup file already removed, confirming @storybook/addon-a11y/preview is applied automatically. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0119LaPQ3v4NyBK3ZTdM9j84
There was a problem hiding this comment.
Pull request overview
Removes obsolete manual Storybook annotation setup in favor of Storybook 10.3+ automatic provisioning.
Changes:
- Removes the redundant setup file and configuration.
- Adds a story guard verifying theme, CSS, and preview annotations.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
clients/web/vite.config.ts |
Removes the Storybook setup file reference. |
clients/web/src/test/PreviewAnnotations.stories.tsx |
Adds annotation-provisioning checks. |
clients/web/.storybook/vitest.setup.ts |
Deletes manual annotation setup. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
The guard restated `primaryShade.light` as a literal 7, so re-pinning the
theme's primary shade would have made it fail even with the preview
annotations correctly applied — a guard that has to be edited alongside a
legitimate theme change just trains people to edit it.
Derive the shade from `theme.primaryShade`, handling both of Mantine's
forms (a bare number and `{ light, dark }`) and falling back to Mantine's
own default of 6 when a theme pins none.
Verified by temporarily re-pinning the theme to `{ light: 8, dark: 8 }`:
the guard still passes, where the hard-coded 7 would have failed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0119LaPQ3v4NyBK3ZTdM9j84
Review round 1 — responsesMirroring the inline reply here, since inline threads go outdated and get hidden once the fix is pushed. 1. Correct, and it undercut the guard's whole purpose: the point was that every expected value is read from the theme, and I restated the shade as a literal anyway. A guard that has to be edited alongside a legitimate theme change just trains people to edit it.
Verified rather than assumed — temporarily re-pinning the theme to (An intermediate attempt with Re-validated after the change: |
Closes #1898
Storybook 10.3+ has
@storybook/addon-vitestprovision the preview annotations itself, and it skips doing so when it finds a setup file callingsetProjectAnnotations— soclients/web/.storybook/vitest.setup.tswas not merely redundant, it was actively opting the project out of the automatic path. Everynpm run test:storybookrun printed the notice saying as much.This removes the file and drops
setupFiles: [".storybook/vitest.setup.ts"]from thestorybookvitest project inclients/web/vite.config.ts.Why this wasn't just a delete
#1898 flagged the silent-failure risk:
./previewcarries theMantineProviderdecorator and theApp.cssimport, and@storybook/addon-a11y/previewdrives the axe assertions. If automatic provisioning didn't pick both up, the 466 story tests would render unthemed with a11y checks inert — and would very likely still pass. A green suite proves nothing here, so both were verified directly rather than inferred.1. Theme decorator — now guarded in-tree
New story
clients/web/src/test/PreviewAnnotations.stories.tsxasserts, from a play function, that the annotations actually reached the story:--mantine-primary-color-filledon:rootequals the project theme's own primary shade (read fromtheme.colors[theme.primaryColor], not hard-coded) — proves theMantineProviderdecorator ran with our theme.--inspector-brand-primaryresolves to the same value — that token lives inApp.css, which only reaches the story through./preview's stylesheet import, and it resolves through the Mantine variable, so it covers both layers.parameters.a11yis{ test: "error" }— the previewparametersmerged into the story context, which is the same channel the a11y parameter arrives on.Negative control: with
decoratorstemporarily emptied in.storybook/preview.tsx, the story goes red. So an unthemed render now fails loudly instead of passing.2. a11y annotations — verified out-of-band
The axe runner can't be introspected from a play function, so this was checked the way the issue asked: a story with a real violation (a
<button>with no accessible name) was temporarily added, and the suite went red with the setup file already removed —confirming
@storybook/addon-a11y/previewis applied automatically. The temporary story was reverted; it is not part of this diff.Verification
npm run test:storybook— 466 tests pass and thesetProjectAnnotationsnotice is gone.npm run validate,npm run verify:build-gate,npm run smoke,npm run ci:storybook— green.npm run coverage— all 315 test files / 4881 tests pass and no file falls below the per-file 90 gate, but the step still exits 1 on the two pre-existing unhandled rejections ininspectorClient.test.tstracked by npm run ci cannot pass: two pre-existing unhandled rejections in inspectorClient.test.ts abort the gate at coverage #1947. Confirmed pre-existing by running the integration project on unmodifiedorigin/v2/mainin the same worktree: identical two rejections, identical exit 1. Unrelated to this diff, which touches only thestorybookvitest project and adds a story.No UI change, so no screenshots.
🤖 Generated with Claude Code
https://claude.ai/code/session_0119LaPQ3v4NyBK3ZTdM9j84