Fixing storybook-addon-apollo-client for Storybook 10

Diagnosed two separate breakages in a community Storybook addon after upgrading to Apollo Client v4 and Storybook 10. One was a moved import path. The other was a subtle cache conflict that nobody had named yet.

Role:Contributor
Apollo ClientStorybookTypeScript
GitHubRepository

While working on Curious, we upgraded Storybook to v10 and Apollo Client to v4 at the same time. The storybook-addon-apollo-client broke. Components stopped rendering, the console was full of errors. It wasn't obvious why.

Turned out it was two separate bugs layered on top of each other.

The first one: a moved import

Apollo Client v4 moved its testing utilities from @apollo/client/testing to @apollo/client/testing/react. The addon was still pointing at the old path.

I opened issue #135, documented the root cause, and submitted PR #136 with the fix: update the import, tighten the peer dependency range for v4.

The maintainer was already working on a broader Storybook 10 migration in PR #139 and absorbed the same change there. During the review, I caught that MockLink.MockedResponse was being used as a type but had been deprecated upstream. I flagged it, installed the canary build, confirmed everything ran correctly, and the PR was merged.

The second one: a cache conflict

After PR #139 landed, most things worked. Then issue #140 showed up. Components were silently failing to render in Storybook 10.1.x.

The thread was going in circles, mostly pointing at Storybook itself. I went back to the actual config.

In our setup, we were passing the app's own InMemoryCache instance into the addon's apolloClient parameter:

TS
// preview.ts
import { cache } from 'src/apollo/client.ts' // InMemoryCache
 
const meta = {
	parameters: {
		apolloClient: {
			cache,
		},
	},
}

Here's the thing about MockedProvider: it creates a fresh InMemoryCache for each story internally. When you hand it a production cache, it uses that instead and the mock interceptor breaks down. Apollo tries to resolve requests against the real cache, finds nothing, and the component silently does nothing.

Removing cache and switching to mocks: [] fixes it:

TS
const meta = {
	parameters: {
		apolloClient: {
			mocks: [],
		},
	},
}

With this in place:

  • MockedProvider creates a fresh InMemoryCache per story
  • No conflict with the app's production cache
  • Apollo Client context is still available for components using useQuery, useMutation, etc.

I posted the diagnosis with both snippets in this comment. The issue was closed shortly after.

Why this matters

storybook-addon-apollo-client is one of 794 addons the Storybook team tracks for Storybook 10 migration. It gets 135,000 downloads a week. When Storybook 10 shipped, every team using Apollo Client with Storybook hit some version of these problems.

The import path fix is easy to find, it's in the changelog. The cache conflict isn't. It fails silently, with no useful error, and nothing in the docs points at MockedProvider's internal cache as the culprit. That's the kind of bug that wastes hours if you don't know what you're looking for.

Posting the root cause publicly means the next person Googling the symptoms finds the answer instead of the silence.