The Platform Around a Story: Core, Frameworks, Builders, and Addons

Storybook presents one preview to the user, but the repository divides the work of producing it across several kinds of package. This chapter examines that platform boundary: what core owns, what a builder and renderer contribute, why a framework package includes more than a renderer name, and how addons cross the manager, preview, and configuration runtimes. The aim is practical judgment. When a story works in one project but not another, the relevant difference is often an environment contract rather than the story itself.

Core preserves the story journey

Storybook’s core package contains the server and CLI, the main manager UI, the preview APIs, and built-in capabilities such as controls, toolbar settings, action logging, viewport handling, and interaction debugging. In the story journey, core is the coordinator. It turns project configuration into an index, connects manager selection to the preview, prepares story context, and exposes the events and APIs that let the surrounding ecosystem participate.

Core is therefore not the same thing as the code that knows how to mount a React, Vue, Angular, or Web Component. It establishes the common lifecycle around that mount. The manager can display a story tree and send a selection. The preview can resolve an indexed identity and prepare annotations. A renderer can then receive a context and produce the component output. Keeping those responsibilities distinct is what lets the story remain recognizable when the component runtime changes.

This separation also gives core a stable place to own state that is not component-specific. The index describes which entries exist. The manager owns navigation, filters, layout, and status presentation. The preview store owns prepared stories and current args or globals. A renderer owns the actual component DOM. The channel carries commands and results across the manager/preview boundary. A component renderer should not need to know how the sidebar sorts stories, and the manager should not need to know how a Vue component mounts.

The boundary is not absolute isolation. Core must expose interfaces that cross it. A builder supplies an importable module graph. A renderer supplies a renderToCanvas-style operation and cleanup. A framework preset tells Storybook which builder and renderer to use and how to adapt the project’s conventions. Addons contribute annotations, UI, or configuration. The story moves through every layer, but each layer should add the smallest responsibility needed to preserve the journey.

The builder supplies the execution environment

A builder connects Storybook to a bundler such as Vite or Webpack. It resolves imports, processes source files, serves or builds the preview, and supports the module updates used during development. The builder is not merely a speed setting. It determines how project code is transformed and which parts of the application’s module environment Storybook can reuse.

In the current Vite path, Storybook assembles a Vite configuration from self-contained plugins. Some plugins establish common settings and external globals; others create virtual entry points for the Storybook application and story imports. A generated import function maps story paths to asynchronous dynamic imports. That lets the index identify stories before their modules execute and gives the bundler a way to split story code into chunks. The builder also connects file changes to the HMR path that invalidates or reloads the active story.