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

Confirmed facts

Storybook’s dev and build commands read the installed Storybook version from package.json and compare it with a hash stored in node_modules/.cache/storybook. If the versions differ, Storybook automatically regenerates the cache. Package managers (npm, Yarn, pnpm) only manage the node_modules tree; they do not inspect or clear Storybook’s cache during dependency installation.

Likely explanation

Because the version check lives inside Storybook, the responsibility for cache invalidation after a Storybook or framework‑addon upgrade falls to Storybook itself—or to any script that invokes Storybook after the upgrade. In practice, running storybook dev or storybook build after an upgrade will trigger a rebuild of the stale cache.

Steps for this case

1. After upgrading Storybook or any of its peer dependencies, run the Storybook command you normally use in development or CI:

# development
storybook dev
# or production build
storybook build --output-dir=storybook-static

2. If you prefer to keep the cache disabled in CI to avoid any risk, add the flag that Storybook provides (check the CLI help for your installed major version, e.g., --disable-cache).
3. In a monorepo where dependency hoisting may scatter node_modules/.cache/storybook across workspaces, locate and clear the caches only when you know a version mismatch exists:

# Example for npm/yarn/pnpm workspaces
find . -type d -path "*/node_modules/.cache/storybook" -exec rm -rf {} +

4. If you cache node_modules between CI runs, include the Storybook version (or a hash of package-lock.json/yarn.lock/pnpm-lock.yaml) in the cache key so that a version bump automatically busts the cache.

These steps ensure that any stale Storybook cache is refreshed without wiping unrelated caches.