In Storybook, a builder is responsible for compiling your components and stories into JS bundles that run in the browser. A builder also provides a development server for interactive development and a production mode for optimized bundles.
To opt into a builder, the user must add it as a dependency and then edit their configuration file (
.storybook/main.js) to enable it. For example, with the Vite builder:
In Storybook, every builder must implement the following API, exposing the following configuration options and entry points:
In development mode, the
start API call is responsible for initializing the development server to monitor the file system for changes (for example, components and stories) then execute a hot module reload in the browser.
It also provides a bail function to allow the running process to end gracefully, either via user input or error.
In production, the
build API call is responsible for generating a static Storybook build, storing it by default in the
storybook-static directory if no additional configuration is provided. The generated output should contain everything the user needs to view its Storybook by opening either the
iframe.html in a browser with no other processes running.
Under the hood, a builder is responsible for serving/building the preview
iframe, which has its own set of requirements. To fully support Storybook, including the Essential addons that ship with Storybook, it must consider the following.
stories configuration field enables story loading in Storybook. It defines an array of file globs containing the physical location of the component's stories. The builder must be able to load those files and monitor them for changes and update the UI accordingly.
By default, Storybook's configuration is handled in a dedicated file (
storybook/main.js|ts), giving the user the option to customize it to suit its needs. The builder should also provide its own configuration support through additional fields or some other builder-appropriate mechanism. For example:
preview.js configuration file allows users to control how the story renders in the UI. This is provided via the decorators named export. When Storybook starts, it converts these named exports into internal API calls via virtual module entry, for example,
addDecorator(). The builder must also provide a similar implementation. For example:
Storybook's Docs includes the ability to author stories/documentation in MDX using a Webpack loader. The builder must also know how to interpret MDX and invoke Storybook's special extensions. For example:
Storybook annotates components and stories with additional metadata related to their inputs to automatically generate interactive controls and documentation. Currently, this is provided via Webpack loaders/plugins. The builder must re-implement this to support those features.
One of Storybook's core features it's the ability to generate a static build that can be published to a web hosting service. The builder must also be able to provide a similar mechanism. For example:
By default, when Storybook starts in development mode, it relies on its internal development server. The builder needs to be able to integrate with it. For example:
The builder must provide a way to stop the development server once the process terminates; this can be via user input or error. For example:
While running in development mode, the builder's development server must be able to reload the page once a change happens, either in a story, component, or helper function.
This area is under rapid development, and the associated documentation is still in progress and subject to change. If you are interested in creating a builder, you can learn more about implementing a builder in Storybook by checking the source code for Vite, Webpack, or Modern Web's dev-server-storybook. When you're ready, open an RFC to discuss your proposal with the Storybook community and maintainers.