<aside> 🧹 @Michael Shilman

</aside>

User stories

<aside> 👩‍💻 As a metaframework (e.g. NextJS) user, I want SB to automatically configure itself with my settings, so I don’t need to do any complicated configuration by hand.

</aside>

<aside> 👩‍💻 As a metaframework user, I want to take on the minimum needed dependencies to reduce my install time/size, and reduce the potential for conflicts.

</aside>

<aside> 👩‍💻 As a SB renderer maintainer (e.g. react, vue), I want my work to be reusable across different metaframeworks/builders without adding dependency bloat.

</aside>

What

Unbundle Storybook’s “framework” concept into two pieces:

• A renderer that’s responsible for render operations (e.g. Vue, React)
• A framework that’s responsible for composing view layers & builders & configuration.

Then:

• Refactor Storybook’s existing frameworks to match this new schema
• Introduce first-class support for some popular metaframeworks like NextJS

Why

Configuring Storybook metaframeworks is a mess. For example, for Create React App (CRA), we currently configure Storybook for React, then throw away its webpack configuration, then reuse CRA’s configuration. And that’s the gold standard! Most metaframeworks are currently supported only with a recipe for how to manually configure Storybook, and these can easily go out of date.

The reason for this confusion is that Storybook 6.x “frameworks” (react, vue, etc.) mix concerns: they include both rendering logic as well as webpack configuration. This means, for example, that if we want to reuse React’s rendering logic but not its webpack configuration (e.g. in the CRA case) we need to do gymnastics. This is even worse if we’re using the Vite builder, where we might be introducing lots of unnecessary Webpack dependencies, that add bloat, potential for conflicts, and security warnings.

By stripping down @storybook/react to its rendering logic only, it becomes easy to reuse in metaframework-specific configurations, such as @storybook/create-react-app.

Prototype