Storybook build cache and package-manager reinstalls: who should invalidate node_modules/.cache/storybook after upgrades?

Integration boundary

Storybook stores its manager and preview build artifacts in node_modules/.cache/storybook, which means the cache directory is owned by the host project's package manager while its contents are produced by Storybook. After upgrading Storybook or framework addons, stale entries in that directory are a documented source of confusing behavior such as blank pages or missing addons, and the documented remedy is manual deletion or running with cache disabled rather than any guaranteed automatic invalidation.

Constraints and uncertainty

Our setup is a monorepo where dependency hoisting makes it ambiguous which Storybook instance owns which cache directory, and our CI caches node_modules between builds for speed, so a stale Storybook cache can survive across pipeline runs. Fresh clones and npm ci implicitly reset the cache, which makes the failures intermittent and environment-dependent. Exact flag names and cache behavior are version-sensitive, so anything scripted must be checked against the installed major version's CLI help.

Open questions

• Should post-upgrade cache hygiene live in package-manager lifecycle scripts, in Storybook's own dev/build invocation, or in CI configuration?
• Is disabling the cache via the CLI flag an acceptable permanent trade-off in CI, or does the startup cost make targeted deletion the better policy?
• In a hoisted monorepo, what is a reliable way to locate and clear every Storybook cache directory without wiping unrelated caches?