dumi's manifest is 2.4.50 while its newest tag is v2.4.46

The README is sixty words and its badge snippet is empty

The document a reader meets first is very short. It names the project, states that dumi is a static site generator for component library development, and points at the official site for usage and guides.

Then there is a contributing line pointing at `CONTRIBUTING.md`, and a licence line.

The badge section is the part with a defect in it. The instruction is to add a README badge to show the project off, and the snippet underneath is an empty image followed by a link:

[](https://github.com/umijs/dumi)

The image part of the markdown has no source, so what the document offers to copy renders as a link with nothing to click on rather than as a badge. It appears twice, once in the sentence above it as a rendered badge and once as the copyable snippet.

So the one piece of this repository that is meant to be copied into another README does not work as printed. For a project whose value proposition is writing documentation, that is a small thing with a disproportionate first impression, and the rest of the guidance is one link away on the official site.

The manifest is ahead of the tags by four patch releases

The version numbers in this project live in two places and they do not match.

`package.json` declares version `2.4.50`. The recent tags are v2.4.46 on 2026-07-16, v2.4.42 on 2026-07-08 and v2.4.41 on 2026-07-07.

So the manifest is four patch releases ahead of the newest tag, which means the working tree contains changes that have never been tagged. Nothing in the repository explains the gap.

The tag cadence itself is worth noting. Three releases inside ten days in July 2026, then nothing since, while the last commit on the default branch is dated 2026-09-14, two months after the newest tag.

The release process is scripted rather than manual: `release` runs a TypeScript file through esno and `release:publish` runs another. So tags and manifest versions are both produced by tooling, and a mismatch between them is a sequencing question rather than a forgotten bump.

The consequence for a consumer is narrow but real. If you install from the registry you get whatever version was last published, and if you read the manifest on the default branch you are reading a number that no tag corresponds to.

The build compiles a Rust crate to WASI with a nightly-only flag

This is a JavaScript package that cannot be built without Rust.

The build script is two commands: the JavaScript build, and then a crates build that reads:

cargo build --target wasm32-wasip1 -r --artifact-dir compiled/crates -Z unstable-options

Three things in that line matter. The target is `wasm32-wasip1`, so the Rust code is compiled to WebAssembly for a WASI platform rather than to a native library. The output goes into `compiled/crates`, and `compiled/` is one of the directories the package publishes, so the WebAssembly artefacts ship inside the npm tarball. And `-Z unstable-options` is a nightly-only cargo flag, which means the build requires a nightly toolchain, with a `rust-toolchain` file and a `rustfmt.toml` at the repository root to pin it.

The Rust side is small. The workspace manifest has exactly one member, a crate named for an SWC React plugin, uses resolver version 2, and enables link time optimisation in the release profile.

So the practical build requirement for a contributor is Node, the father build tool, and a nightly Rust toolchain with a WASI target installed. For a consumer there is no such requirement, since the compiled output is already in the package.

npm install on a clone builds the package and syncs docs from umi

The `prepare` script is the reason a fresh clone takes a while, and it is worth reading as a whole.

It installs the husky hooks, runs the build, runs the suite builds, runs a `dumi setup` step, and then runs a docs sync. Every one of those is work, and npm runs `prepare` after an ordinary `npm install` in a repository checkout.

The docs sync is the surprising one: it runs `node ./scripts/sync-from-umi.js`. Documentation in this repository is partly pulled from the umi repository rather than authored in place, which means a contributor working on docs may be editing content that a script overwrites, and a release carries whatever the sync produced at that moment.

The suite build is a workspace filter over `./suites/**`, and there is a `suites/` directory at the root that the README never mentions. Whatever lives there is built separately from the main package.

There is also a dependency pre-bundle step, a worker script followed by `father prebundle`, which runs before packaging rather than as part of it.

Three bundler configurations live in one repository

The build tooling is not one bundler with options; it is several.

The primary path is father. `build` and `dev` both call it, `.fatherrc.ts` configures it, and `build:deps` runs a pre-bundle worker followed by `father prebundle`.

Then there is Mako, with a `mako.config.json` at the root, which is the bundler the Umi ecosystem has been moving toward.

Then there is Utoopack. It appears twice: as a keyword in the manifest and as an example directory named `normal-utoopack` beside `normal`, `mobile`, `temp` and `vue`.

So the repository carries a webpack-lineage build, a Mako build and an Utoopack-oriented example, and the manifest advertises Utoopack as a keyword. For a documentation generator that has to run inside other people's toolchains, supporting more than one bundler is the point rather than an accident, but it does mean the compatibility surface is three configurations deep.

The examples are also the clearest statement of what the generator is expected to handle, and one of them is Vue while the manifest describes React.

The package description says React and the examples include Vue

There are two different one-line descriptions in play, and they do not say the same thing.

The repository description is a static site generator for component library development. The manifest description is a documentation generator of React component, with a small emoji in front of it.

The examples directory disagrees with the narrower of the two. Alongside `normal`, `mobile` and `temp`, there is a `vue` example, and alongside those there is `normal-utoopack`.

So the project presents itself as a React documentation generator, ships a Vue example, and its own README declines to describe either. What the examples actually demonstrate is broader than the description, which is the usual direction for a mismatch to go.

The published surface matches the manifest rather than the README. The `files` array lists `bin`, `dist`, `compiled`, `theme-default`, seven declaration or utility files, and the source of those utilities as both JavaScript and TypeScript declarations. So a consumer gets a default theme, a command line entry at `bin/dumi.js` and a library entry at `dist/index.js`.

Lint runs over src and test and nothing else

The quality tooling is conventional and slightly narrow.

`lint` is two commands: eslint over `{src,test}/**/*.{js,jsx,ts,tsx}` and stylelint over `{src,test}/**/*.{css,less}`. Both patterns name the same two directories, so `examples/`, `suites/`, `docs/`, `scripts/` and `bin/` are outside the linted set.

Formatting is broader: prettier runs over the whole repository with a cache.

The configuration files are all in the older formats, an eslintrc file, a stylelint config and a prettierrc, with matching ignore files for eslint and prettier.

Package management is pnpm, with a workspace file, a lockfile and an npmrc at the root. Tests run under Vitest with a configuration file at the root, and there is a `typings/` directory alongside the tests.

The published declarations deserve a note. `types` points at `index.d.ts` at the repository root while `main` points at `dist/index.js`, so the type entry is a hand-maintained shim rather than the declarations emitted by the build. Five more root-level declaration files are published individually, covering the types, the theme API, the theme modules, and the plugin and tech stack utilities.

Editorial conclusion

Dumi fits a team shipping a React component library that needs documentation generated from the same markdown it keeps in the repository, with a default theme and a demo per framework arrangement rather than a hand-built docs site. Three things to check before you adopt it. Check the build story, because the package build compiles a Rust crate to a WASI target using a nightly-only cargo flag, so a clone needs a Rust toolchain in addition to Node. Check what runs when you install from a clone, since the prepare script builds the package, builds the suites, runs a setup step and syncs documentation from the umi repository. And check the version relationship, since the manifest sits at 2.4.50 while the newest tag is v2.4.46, so the published artefact and the repository history are not the same number. MIT licensed, a documentation site at d.umijs.org, pnpm at the root, and a lint setup that covers only two directories.

Frequently asked questions

Official sources

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