dumi: a static site generator for React component libraries

The problem dumi solves for component library authors

A component library has two audiences that normally need two artifacts. Consumers need prose: what a prop does, when to use the component, what changed in the last release. Developers need to see the thing running, with knobs to turn. Teams usually solve this by keeping a README next to the source and a separate demo app somewhere else, then watching the two drift apart.

dumi collapses that into one tree. The repository describes itself as a static site generator for component library development, and the package description goes further: documentation generator of React component. The unit of authoring is a Markdown file, and inside that file you can embed a live component. The output is a static site, so the docs deploy the same way any other static bundle does.

The intended user is the maintainer of a React component package. If your library ships to npm and other people import it, dumi is aimed at you. If you are writing a product manual or a blog, the demo embedding machinery is weight you will not use.

How dumi turns Markdown into a demo site

The repository layout tells most of the story. There is a .dumirc.ts at the top level, the same config-file convention umi uses, plus a .dumi/ directory for project-local overrides. The package exposes a bin entry at ./bin/dumi.js, so the CLI is the entry point rather than a library you import.

Under the hood the build is not a thin Markdown-to-HTML pass. The package.json lists a Rust workspace: Cargo.toml declares a member crate named crates/swc_plugin_react_demo, and the build script compiles crates with cargo build --target wasm32-wasip1 into compiled/crates. That crate name is the giveaway. Demo code inside Markdown is transformed by an SWC plugin, shipped as WebAssembly, which is how the tool can compile a fenced code block into a rendered React component at build time.

So the data flow is: Markdown file in, code blocks identified as demos, those blocks compiled through the WASM plugin, the result assembled into a static site by the umi build pipeline. The compiled/ directory in the published package exists because the WASM artifacts have to ship with the npm tarball; the files array in package.json confirms that compiled/ is included.

The presence of Cargo.lock, rust-toolchain and rustfmt.toml at the repository root is a real constraint for contributors. Building dumi from source needs a Rust toolchain in addition to Node, and the build script uses the unstable -Z unstable-options flag, which means a nightly toolchain. That is fine for the maintainers and invisible to users installing from npm, but it is worth knowing if you plan to patch the demo compiler.

Installing dumi and rendering a first component

The README points to the official site at d.umijs.org for usage and guide material; the repository itself does not spell out an install command. What the repository does establish is the package name and the CLI binary. The package is published as dumi on npm, and package.json declares "bin": "./bin/dumi.js".

The repository's own scripts show the two commands the CLI supports in practice. Its docs:dev script runs node ./bin/dumi.js dev and its docs:build script runs node ./bin/dumi.js build. Those are the same subcommands a consumer gets from the installed binary, so a typical local workflow looks like this:

npm install dumi --save-dev
npx dumi dev

After that the dev server serves the site and watches your Markdown. When you are ready to ship, the build subcommand produces the static output:

npx dumi build

Configuration lives in .dumirc.ts at the project root, matching the file present in this repository. The README does not document individual config keys, so treat that file as the place to look rather than expecting a full key reference in the README.

The repository also carries examples/ directories, including examples/normal/, examples/mobile/, examples/vue/ and examples/normal-utoopack/. Those are the maintainers' own fixtures, not a tutorial, but they are the most concrete reference for how a dumi project is laid out. Note the vue example: it exists, but the package keywords and description are React-specific, and the demo compiler crate is named swc_plugin_react_demo. Do not read the presence of that example as a promise of first-class Vue support.

Where dumi gets in your way

The strongest limitation is the coupling. dumi is built on umi and shares its configuration conventions, its plugin model and its build pipeline. That is the source of most of its convenience and most of its friction. If your team already runs umi, dumi slots in with almost no new concepts. If you do not, you are adopting a framework to get a docs site.

The Rust dependency is a second constraint, though it lands mostly on contributors rather than users. Building the package from source requires a Rust toolchain and, because of the -Z unstable-options flag in the build:crates script, a nightly one. Anyone who wants to modify the demo transform rather than just use it is signing up for that.

Third, the README is thin. It links to the official site for usage and guide material and does not document install steps, config keys or the CLI surface inline. That is a deliberate choice, but it means the repository alone will not get a new user very far, and it makes the docs site a single point of failure for onboarding.

Finally, the static output is a docs site, not an application. If you need authenticated pages, server-side rendering per request, or a search index built at query time, dumi's output model is the wrong shape. It generates files.

dumi against Storybook and against plain VitePress

The obvious comparison is Storybook. Both render components in isolation with controls. The difference is the artifact. Storybook produces a component workshop, organized around stories, with the docs layer bolted on top. dumi produces a documentation site, organized around Markdown pages, with live demos embedded inside the prose. If your primary output is a written guide that happens to contain running examples, dumi's model fits better. If your primary output is a catalogue of every component state for designers and QA, Storybook's does.

The second comparison is a Markdown-first static site generator such as VitePress. VitePress will render your Markdown beautifully and will not compile your demo code blocks into live components without extra work. dumi's whole reason to exist is that extra step. Choosing VitePress means you keep a lighter dependency tree and give up the built-in demo pipeline.

There is also a version dimension worth noting. The recent releases listed for this project are all in the 2.4.x line, with the most recent at 2.4.46 from 2026-07-16, while package.json in the repository declares 2.4.50. The last push to the default branch was on 2026-09-14. That is a project still moving, not a frozen one.

Licence and the cost of keeping up

dumi is MIT licensed, stated in both the README and package.json. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text travel with it. That is a summary of what the licence identifier means, not legal advice; if your organisation has a policy on third-party licences, run it through that process.

The upgrade cost is mostly the umi cost. Because dumi tracks umi's config and plugin conventions, a major umi change can ripple into your .dumirc.ts and any local plugins. The 2.4.x releases above are patch-level within a minor line, which suggests incremental change rather than churn, but the repository does not publish an upgrade guide, and the README does not document a migration path between major versions. Plan for reading release notes rather than following a documented upgrade procedure.

There is also a supply-chain surface worth naming: the published tarball includes a compiled/ directory containing WASM artifacts built from the Rust crate. You are installing prebuilt binaries, not source you compile yourself. That is normal for npm packages with native components, but it is a fact about what npm install dumi actually pulls down.

Editorial conclusion

Adopt dumi if you are shipping a React component library and want the demos and the prose in one Markdown tree, and you accept the umi build stack that comes with it. Do not adopt it for a Vue project, a plain marketing site, or a docs set that needs no live examples. Before committing, run the dev server against one real component, check that your existing docs render under the dumi theme, and confirm the release cadence on npm matches how often you ship.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. umijs/dumi on GitHub