Overview

Purpose and Scope

Storybook is presented by this repository as a frontend workshop for building UI components and pages in isolation. The public README summarizes the product promise as building bulletproof UI components faster, while the docs landing page explains the practical reason: developers can work on hard-to-reach states and edge cases without running the whole application. That framing matters because Storybook is not only a renderer or a test runner. It is a workspace that combines isolated component development, interactive inspection, documentation, and sharing into one UI-focused development loop.

Sources: README.md, docs/index.mdx

The monorepo supports that product by combining documentation, package source, framework integrations, builders, addons, and contributor tooling. At the repository root, package.json declares a private workspace named @storybook/root and includes workspaces for code, code/addons/*, code/builders/*, code/core, code/frameworks/*, code/lib/*, code/presets/*, code/renderers/*, and scripts. That workspace layout is the high-level map for readers who want to connect the public docs to implementation areas. The docs teach concepts and workflows, while the code packages supply the CLI, manager UI, preview behavior, addons, builders, and ecosystem libraries that make those workflows run.

Sources: package.json, code/core/README.md

Relevant Source Files

• README.md — Public repository landing page that defines Storybook as a frontend workshop and points readers to getting started, documentation, examples, addons, community, and contribution paths.
• docs/index.mdx — Docs homepage source that introduces the install path, supported frameworks, community-maintained frameworks, main concepts, AI setup prompt, and additional resources.
• code/core/README.md — Core package overview that names the CLI, development server, manager UI, controls, toolbars, action logging, viewport control, interaction debugger, user-facing utility libraries, and internal utilities.
• package.json — Root workspace and script manifest showing how the monorepo is organized and which top-level commands drive development, tests, docs checks, formatting, ecosystem CI, and Storybook UI test projects.

Core Product Model

A Storybook project is organized around stories: small examples of component states rendered outside the full application shell. The docs homepage describes Storybook as a way to develop and share hard-to-reach states and edge cases, which is why the documentation spine begins with installation, frameworks, the definition of a story, browsing a running Storybook, and setup. Those early topics form the basic reader path: install the tool, connect the appropriate renderer or framework, learn how component examples are represented, and then use the UI to inspect and iterate on them.

Sources: docs/index.mdx, README.md

The repository README and docs homepage both emphasize three recurring use cases: UI development, testing, and documentation. In practice, these are not separate products bolted together after the fact. A story that demonstrates a component state can also feed interactive controls, automated interaction tests, accessibility checks, visual review, and generated documentation. That reuse explains why the official documentation tree puts story authoring near the beginning, followed by Essentials, Docs, Testing, Configure, Builders, Addons, API, Sharing, Releases, and Contribution. The same component examples become the shared unit of work across most Storybook capabilities.

Sources: README.md, docs/index.mdx

System-to-Code Mapping

The storybook core package is the central implementation anchor described by code/core/README.md. It contains Storybook's CLI and development server, the main UI known as the manager, core functionality such as component controls, toolbar controls, action logging, viewport control, and the interaction debugger, plus user-facing utility libraries including storybook/test, theming, and viewport. The same README also identifies libraries under the storybook/internal namespace for CSF, MDX, and Docs, which connects the public authoring formats to shared internal utilities used by frameworks, addons, and builders.

Sources: code/core/README.md

The root workspace configuration shows how those responsibilities are split across packages. Framework-specific support lives under code/frameworks/*, renderer packages under code/renderers/*, builder integrations under code/builders/*, addon packages under code/addons/*, presets under code/presets/*, shared libraries under code/lib/*, and repository automation under scripts. This separation lets Storybook present one documentation experience while supporting many view layers and build systems. When you are tracing a feature, start with the concept in docs, identify whether it is core, addon, builder, framework, renderer, or script behavior, and then follow the matching workspace group.

Sources: package.json, code/core/README.md

Documentation Paths

The docs landing page is intentionally task-oriented. It starts with an installation command component and an AI-agent setup callout, then moves to supported frameworks, community-maintained frameworks, main concepts, and additional resources. That ordering gives new users a path from zero to a running workshop before they dive into deeper references. The official docs navigation further divides the product into Get Started, Stories, Testing, Docs, AI, Sharing, Essentials, Addons, Configure, Builders, API, Releases, Contribute, and FAQ. For a developer reading this OpenWiki, those sections should be treated as the main conceptual index for the monorepo.

Sources: docs/index.mdx

The development path is centered on stories and configuration. Readers learning Storybook should start with what a story is, then Component Story Format, args, arg types, parameters, decorators, loaders, play functions, naming, hierarchy, and TypeScript patterns. These concepts explain how a component state is declared, how inputs are controlled, how environment and provider wrappers are applied, and how scripted interactions are attached. The implementation evidence for this overview does not enumerate every API, but the core README explicitly ties Storybook core to CSF utilities, controls, toolbar controls, and interaction debugging, so these subjects are part of the core platform surface.

Sources: code/core/README.md, docs/index.mdx

The testing and documentation paths are equally important. Storybook's public positioning names testing and documentation alongside UI development, and the core package README names storybook/test as a user-facing utility library. Documentation features are represented in the docs tree through Autodocs, MDX, doc blocks, the code panel, and preview/build docs workflows. Testing topics include interaction tests, accessibility tests, visual tests, snapshot tests, coverage, and CI. The useful mental model is that stories are the source examples, docs convert them into readable component references, and tests exercise them as browser-rendered scenarios.

Sources: README.md, code/core/README.md

Addons, Builders, and Sharing

Addons extend Storybook beyond the core workshop experience. The official addon documentation describes addons as feature and integration packages, and the monorepo layout reflects that with a dedicated code/addons/* workspace. The core README also shows that several capabilities users experience as first-class UI features, such as controls, action logging, viewport control, toolbars, and the interaction debugger, are part of the core package surface. When evaluating an addon-related change, distinguish between the public addon configuration model, addon packages that ship in this repository, and core APIs exposed to manager and preview code.

Sources: package.json, code/core/README.md

Builders and frameworks are the integration layer between Storybook and an application's technology stack. The root workspaces allocate builders to code/builders/*, frameworks to code/frameworks/*, and renderers to code/renderers/*, which mirrors the docs sections for framework setup and builder configuration. A framework package typically answers how Storybook understands a project type, while a builder package answers how the preview iframe is bundled for development or static output. This overview page does not replace the detailed Vite, Webpack, React, Vue, Angular, Svelte, Web Components, or other framework pages; it explains where those topics fit in the repository map.

Sources: package.json

Sharing is the final stage of the workflow. The README points users to examples and the Storybook website, and the official docs include publish, embed, design integrations, composition, and package composition. The common thread is that an isolated component workshop becomes a communication artifact for teammates, designers, QA, and external consumers. In source terms, sharing depends on the same core primitives already described: stories to define examples, docs to explain them, builders to produce static output, and addons or integrations to connect Storybook with design and review workflows.

Sources: README.md, docs/index.mdx

Development and Maintenance Signals

The root package.json gives contributors the first concrete signals for maintaining the repository. It uses Yarn 4.10.3 and exposes scripts for installing dependencies, running tests with Vitest, watching tests, linting the code workspace, checking docs through scripts, formatting with oxfmt, running Nx, starting a development task against the react-vite/default-ts template, and executing ecosystem CI flows for Vite and Svelte. These scripts show that local and CI workflows are organized around the monorepo's package graph rather than a single application entry point.

Sources: package.json

Useful top-level commands visible from the root manifest include:

yarn
yarn start
yarn test
yarn test:watch
yarn lint
yarn docs:check
yarn fmt:check
yarn nx

For next steps, read this overview as the orientation page and then choose a path based on the work you need to do. New users should continue to installation and setup, then learn stories and browsing. Component authors should read the writing-stories and Essentials pages. Documentation owners should move to Autodocs, MDX, doc blocks, and docs builds. Test authors should start with interaction testing, accessibility testing, coverage, and CI. Integrators and maintainers should continue to framework, builder, addon, CLI, and contribution pages, using the workspace mapping above to connect each concept back to the relevant package area.

Sources: docs/index.mdx, package.json