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
{{ message }}
Repository navigation
Storybook 10 migration: the family must bump in lockstep + play-function Canvas API changed #425
Diagnosed 2026-07-30 after refreshing bun.lock on the two open Dependabot PRs so their CI reached real work instead of dying at bun install --frozen-lockfile.
Storybook requires every one of its packages on the same major. The two PRs each move half the family, so each fails differently:
#413 (@storybook/react-vite 9.1.20 → 10.5.4) pulls @storybook/react@10.5.5, @storybook/builder-vite@10.5.5 and @storybook/csf-plugin@10.5.5, while storybook core stays at 9.1.20:
No matching export in "../../node_modules/storybook/dist/preview-api/index.js"
for import "Tag"
at node_modules/@storybook/react/dist/_browser-chunks/chunk-7HUHAOMV.js:20
import { Tag } from "storybook/internal/preview-api";
@storybook/react@10 imports Tag from a preview-api surface that does not exist in core 9.
#414 (storybook 9.1.20 → 10.5.5) moves core but leaves @storybook/react-vite at 9.1.20 — and bun then resolves a nestedstorybook@9.1.20 under every @storybook/* package (@storybook/react/storybook, @storybook/react-vite/storybook, @storybook/addon-vitest/storybook, @storybook/addon-a11y/storybook, @storybook/builder-vite/storybook, @storybook/csf-plugin/storybook, @storybook/react-dom-shim/storybook), so two cores coexist in one install.
The real migration work
Bump the whole family in one change — all currently ^9.1.20: storybook, @storybook/react-vite, @storybook/addon-vitest, @storybook/addon-a11y.
The play-function Canvas API changed. Storybook 10 no longer exposes testing-library queries on the Canvas object, so every play function using them fails to typecheck with error TS2339: Property '<name>' does not exist on type 'Canvas'. Sites from the chore(deps-dev): bump storybook from 9.1.20 to 10.5.4 #414 run:
That list is truncated at the 12 log lines I captured — expect more once the family is consistent and typecheck runs to completion.
New peers to check: storybook@10 declares @types/react and vite-plus as peer dependencies, and widens its vite range to include ^8.
Recommended handling
Ship this as one deliberate migration PR rather than through Dependabot, and close #413/#414 when it lands. Both PRs now carry a refreshed lockfile, so their CI output is real signal and worth reading while migrating.
Worth considering alongside it: a Dependabot group for the storybook family that includes majors, e.g. patterns: ["storybook", "@storybook/*"]. That does not conflict with the #398 decision to ungroup majors — that rationale was "one migration per PR", and the Storybook family is one migration whose packages must move in lockstep. Without a group, every future Storybook major arrives as N individually-unmergeable PRs. Left as a suggestion rather than applied, since #398 was a deliberate policy call.
Diagnosed 2026-07-30 after refreshing
bun.lockon the two open Dependabot PRs so their CI reached real work instead of dying atbun install --frozen-lockfile.Neither #413 nor #414 can EVER pass on its own
Storybook requires every one of its packages on the same major. The two PRs each move half the family, so each fails differently:
#413 (
@storybook/react-vite9.1.20 → 10.5.4) pulls@storybook/react@10.5.5,@storybook/builder-vite@10.5.5and@storybook/csf-plugin@10.5.5, whilestorybookcore stays at 9.1.20:@storybook/react@10importsTagfrom apreview-apisurface that does not exist in core 9.#414 (
storybook9.1.20 → 10.5.5) moves core but leaves@storybook/react-viteat 9.1.20 — and bun then resolves a nestedstorybook@9.1.20under every@storybook/*package (@storybook/react/storybook,@storybook/react-vite/storybook,@storybook/addon-vitest/storybook,@storybook/addon-a11y/storybook,@storybook/builder-vite/storybook,@storybook/csf-plugin/storybook,@storybook/react-dom-shim/storybook), so two cores coexist in one install.The real migration work
Bump the whole family in one change — all currently
^9.1.20:storybook,@storybook/react-vite,@storybook/addon-vitest,@storybook/addon-a11y.The play-function
CanvasAPI changed. Storybook 10 no longer exposes testing-library queries on theCanvasobject, so everyplayfunction using them fails to typecheck witherror TS2339: Property '<name>' does not exist on type 'Canvas'. Sites from the chore(deps-dev): bump storybook from 9.1.20 to 10.5.4 #414 run:settings/ClaudeNotifyHook/ClaudeNotifyHook.stories.tsx—getByRole×2,getByTextterminal/TerminalGrid/TerminalGrid.stories.tsx—getAllByRole×2,getByRole,queryByRole,getByText,getByLabelText,getAllByTextterminal/TerminalGridPane/TerminalGridPane.stories.tsx—getByRole×2That list is truncated at the 12 log lines I captured — expect more once the family is consistent and typecheck runs to completion.
New peers to check:
storybook@10declares@types/reactandvite-plusas peer dependencies, and widens its vite range to include^8.Recommended handling
Ship this as one deliberate migration PR rather than through Dependabot, and close #413/#414 when it lands. Both PRs now carry a refreshed lockfile, so their CI output is real signal and worth reading while migrating.
Worth considering alongside it: a Dependabot group for the storybook family that includes majors, e.g.
patterns: ["storybook", "@storybook/*"]. That does not conflict with the #398 decision to ungroup majors — that rationale was "one migration per PR", and the Storybook family is one migration whose packages must move in lockstep. Without a group, every future Storybook major arrives as N individually-unmergeable PRs. Left as a suggestion rather than applied, since #398 was a deliberate policy call.