new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Storybook · Writing and testing · all subjects

documentation/build

19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Hosting providers for published documentation

Storybook documentation can be published to various hosting providers including Vercel, Netlify, and S3.

Build documentation with --docs flag

To build documentation for publishing, use the --docs flag with the storybook build command. This can be set up as a script in package.json like: storybook build --docs

Documentation mode build output location

When building documentation with storybook build --docs, the output is placed in the storybook-static folder.

Documentation can be customized with MDX pages or Autodocs template

You can customize the Autodocs template or create free-form pages for each component using MDX. Both approaches use Doc Blocks as building blocks to create full-featured documentation.

Stories serve as basic documentation during component development

When you write component stories during development in Storybook, you automatically create basic documentation that can be revisited later. This foundation can be expanded with additional prose and layout.

Doc Blocks are the building blocks for documentation

Doc Blocks are the fundamental components used to construct full-featured documentation in Storybook, whether using Autodocs or custom MDX pages.

Docs addon is autoconfigured to work out of the box

The Docs addon in Storybook is autoconfigured to work out of the box in most use cases. In some cases, you may need or want to tweak the configuration.

Use Playwright image in CI for Storybook tests

Storybook Test uses Playwright to render stories by default. For the fastest CI experience, you should use a machine image that has Playwright already installed, such as mcr.microsoft.com/playwright:v1.58.2-noble. This avoids needing to install Playwright browsers during the CI run.

GitHub Actions CI workflow configuration for Storybook tests

Create a file at .github/workflows/test-ui.yml with the following structure: use ubuntu-latest runner with the Playwright image mcr.microsoft.com/playwright:v1.58.2-noble as a container, checkout the repo with actions/checkout@v4, setup Node v22.12.0 with actions/setup-node@v4, run npm ci to install dependencies, and run npm run test-storybook to execute tests.

Debug test failures in CI with deployment URL

When a Storybook test fails in CI, failure output includes a link to the failing story, but in CI there is no active Storybook running at localhost:6006. To provide useful story links in CI, you must first build and publish your Storybook, then pass its URL to the Vitest addon using the SB_URL environment variable. Many CI services emit a deployment_status event containing the published URL under deployment_status.environment_url. Pass this URL to the test command and configure the Vitest plugin to use the storybookUrl plugin option.

Calculate code coverage for Storybook tests

You can calculate code coverage for Storybook tests by passing the --coverage flag to the vitest command. You can either add it to the package.json script 'test-storybook': 'vitest --project=storybook --coverage', or pass it only in CI by adjusting the workflow to run 'npm run test-storybook -- --coverage'. Coverage is most useful when calculated comprehensively across all tests in your project.

Run multiple Vitest projects in CI workflow

If your project has other Vitest tests (e.g., unit tests) in addition to Storybook tests, create separate scripts in package.json for each project using the --project filter: 'test-storybook': 'vitest --project=storybook' and 'test-unit': 'vitest --project=unit'. In your CI workflow, call these scripts independently or together. Alternatively, you can run all tests together by omitting the --project filter and using a single 'test': 'vitest' script.

GitLab Pipelines CI configuration for Storybook tests

Create a file at .gitlab-ci.yml. Define stages with UI_Tests. Set image to node:jod, and cache npm dependencies at .npm/. In the before_script, run npm ci. Define a Test job in the UI_Tests stage with image mcr.microsoft.com/playwright:v1.58.2-noble and script running npm run test-storybook.

Bitbucket Pipelines CI configuration for Storybook tests

Create a file at bitbucket-pipelines.yml. Set image to node:jod. Define npm cache at $HOME/.npm. In the default pipeline, create a stage named 'UI Tests' with a step named 'Run Tests' that uses image mcr.microsoft.com/playwright:v1.58.2-noble, caches npm and node, and runs npm ci followed by npm run test-storybook.

Circle CI configuration for Storybook tests

Create a file at .circleci/config.yml. Define version 2.1. Create a ui-testing executor using Docker image mcr.microsoft.com/playwright:v1.58.2-noble with working_directory ~/repo. Define a Test job that checks out code, restores cache from package-lock.json, runs npm ci, runs npm run test-storybook, and saves the npm cache.

Travis CI configuration for Storybook tests

Create a file at .travis.yml. Set language to node_js, os to linux, and dist to jammy. Specify node_js version 20. In before_script, run npm ci && npm run playwright install chromium --with-deps to install dependencies and Playwright browsers for Vitest browser mode. Cache npm. Define a job in the 'UI Tests' stage that runs npm run test-storybook.

Jenkins CI configuration for Storybook tests

Create a file named JenkinsFile. Define a pipeline with agent any and tools nodejs 'node'. Create a stage 'UI Tests' with a Docker agent using image mcr.microsoft.com/playwright:v1.58.2-noble and reuseNode true. In the steps, run sh 'npm ci' and sh 'npm run test-storybook'.

Azure Pipelines CI configuration for Storybook tests

Create a file at azure-pipelines.yml. Set trigger to main branch. Use ubuntu-latest vmImage in pool. Define a UI_Tests stage with a Test job. Set container to mcr.microsoft.com/playwright:v1.58.2-noble. Set npm_config_cache variable to $(Pipeline.Workspace)/.npm. Add tasks: UseNode@1 to install Node.js v22.12.0, Cache@2 to cache npm with key 'npm | "$(Agent.OS)" | package-lock.json', a script task to run npm ci (if cache not restored), and CmdLine@2 to run npm run test-storybook.

Alternative to Vitest addon: test-runner for CI testing

If you cannot use the Vitest addon in your project, you can still run your stories as tests in CI using the test-runner. Follow the instructions in the test-runner documentation to set up the test-runner to run in CI in your project.

Give your agent this brain