[Bug]: AI manifests/snippets ignore external demo source and docs.source.code when CSF stories render imported wrapper components

[geraldlrh]

Describe the bug

When a CSF story uses an imported wrapper/demo component, Storybook AI manifests generate the story snippet from the wrapper usage in the .stories.tsx file instead of
the actual demo source.

For example, if the story is written like this:

import type { Meta, StoryObj } from '@storybook/react';
import { Button } from 'antd-mobile';
import React from 'react';
import _Demo01 from './demo01';

const meta = {
  title: 'General/Button',
  component: Button,
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Demo01: Story = {
  name: 'Page',
  render: () => <_Demo01 />,
};

and ./demo01.tsx contains the actual example source, the generated manifest snippet is still something like:

const Demo01 = () => <_Demo01 />;

instead of the real source from demo01.tsx.

This also appears to ignore parameters.docs.source.code / docs.source.originalSource as an override for the AI manifest snippet.

Actual behavior

The manifest snippet is based on the inline story render wrapper from the .stories.tsx file:

const Demo01 = () => <_Demo01 />;

Expected behavior

One of the following should happen:

1. Storybook should respect parameters.docs.source.code / docs.source.originalSource for AI manifest snippets.
2. Or Storybook should provide a hook/plugin API to preprocess story source before snippet extraction.
3. Or Storybook should support resolving simple imported wrapper components when generating snippets.

At minimum, it would be helpful if the behavior were documented clearly.

Why this is a problem

A common pattern is to keep demos/examples in separate files and keep .stories.tsx minimal. In that setup, the generated AI manifest snippet becomes low-value because it
only shows the wrapper component usage, not the actual example code.

Reproduction link

example code see above

Reproduction steps

1. Create a story file that imports an external demo/wrapper component:

   import _Demo01 from './demo01';

   export const Demo01: Story = {
   render: () => <_Demo01 />,
   };

2. Put the actual example implementation in demo01.tsx.

3. Run Storybook with AI manifests enabled.

4. Inspect the generated manifest.``

System

- Storybook: 10.3.4
  - @storybook/csf-plugin: 10.3.4
  - storybook-react-rsbuild: 3.3.2
  - React: 19
  - Builder: Rsbuild / Rspack
  - Node: 24.11.1

Additional context

Technical context

From local inspection, the source snippet generation seems to happen in @storybook/csf-plugin, where the loader reads the raw .stories.tsx file from disk and parses that
source again for CSF enrichment. In other words, bundler/runtime transforms do not affect the snippet extraction path.

That means:

• transforming the story at bundler level does not help
• overriding docs.source.code also does not appear to affect the AI manifest snippet

This makes it difficult to customize snippet generation for stories that delegate rendering to external demo files.

Question

Is this the intended behavior for AI manifests/snippets, or would you consider supporting an override/preprocess mechanism for this use case?

[dosubot]

Hi @geraldlrh! I'm Dosu and I’m helping the storybook team.

Your analysis is accurate. The AI manifest snippet generation uses its own AST-based extraction pipeline (getCodeSnippet() in generateCodeSnippet.ts) that operates independently from the parameters system [1]. It does not read parameters.docs.source.code or parameters.docs.source.originalSource — those only affect the Storybook UI/Docs display [2].

For imported wrapper components, the manifest generator uses a tri-state resolution system [3]:

• Local definitions (function/variable declarations in the same file) → resolved and inlined
• Imported references (from other modules) → marked unresolved and replaced with a synthesized JSX placeholder using meta.component

So render: () => <_Demo01 /> with an imported _Demo01 will produce a synthesized snippet like () => <Button /> rather than the actual demo source.

There is currently no manifest-specific customization hook to preprocess or override snippets. The experimental_enrichCsf hook exists for UI docs but doesn't affect manifest generation [4].

Workarounds for now:

• Inline the render function directly in the story file so the AST extraction can capture it
• Co-locate the demo code as a local function/variable in the .stories.tsx file instead of importing it — resolveIdentifierInit() can then find and inline local definitions [5]

Your feature requests (respecting docs.source.code in manifests, or providing a preprocessing hook) seem like reasonable enhancements. The architectural gap between runtime parameters (UI docs) and build-time static analysis (manifests) is the root cause here. A manifest-specific enrichment hook or having extractStories() read source parameters from story metadata would address this.

Related: there are also open issues around import resolution in manifests for ESM extensions [6] and monorepo packages [7], which share the same underlying limitation of the static analysis approach.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}