umi's README lists maintainers and links, and nothing else

The README is a maintainer directory with three links in it

Count what is actually there. Four badges, a sentence saying umi is a framework in the react community, a request to follow the author sorrycc and star the project, then two links: a launch post at https://umijs.org/blog/umi-4-rc and a Learn Umi link to https://umijs.org/. After that comes the Contribution link, three Core Maintainers, nine Maintainers, a Contributors section, a community group at https://fb.umijs.org/, and MIT.

What is missing is the list you came for. No install command, no feature description, no configuration key, no code sample, no requirements. So the question a reader arrives with, what does this framework actually configure for me, cannot be answered from this file, and the honest answer is that the README sends you to the documentation site for it.

The repository metadata is no better. Its description repeats the same phrase twice and then breaks off mid sentence in a request to star the project. It is not a substitute for the feature list either.

The root package is private, so the repo is not what you install

The README carries three badges pointing at https://www.npmjs.com/package/umi, so that is where the package is meant to be found. It never spells out the install, and the root of this repository is not the artifact. The root package.json opens with `"private": true` and a repository field reading `[email protected]:umijs/umi.git`.

Read that as a workspace rather than a product. Alongside it sit pnpm-workspace.yaml, pnpm-lock.yaml, turbo.json, lerna.json and directories named packages/, libs/, ui/, scripts/, docs/, examples/ and test/. There is also a `preinstall` script that shells out to `npx only-allow`, which is how the project keeps a package manager other than the one it uses out of the tree.

The practical consequence for someone evaluating umi is that the repository is a development workspace rather than the artifact: you install the published package and read the site.

Two bundler demos, and five example directories named after one subsystem

The examples directory holds 25 projects, and two of them decide a question the README leaves open. There is a bundler-vite-demo and a bundler-webpack-demo, sitting next to each other. Nothing above them explains whether one is the future and the other is history, or whether you choose at install time.

Five more directories carry mfsu in their names: bug-mfsu-fast-refresh, mfsu-circular-dependency, mfsu-e2e, mfsu-esbuild-less-demo and mfsu-independent-e2e. One of them is named for a bug rather than a feature, which tells you the subsystem has had trouble. The README does not define the acronym, does not say whether the subsystem is on by default, and does not say what breaks when it is off.

Five of twenty-five examples is a fifth of the example surface spent on one thing the front page never mentions. If your evaluation depends on that subsystem, you are reading example directories and issues to answer a question the documentation site would answer in a paragraph.

A React framework that ships a Vue boilerplate and a Module Federation pair

Two directories in examples/ are named for ecosystems rather than features. boilerplate is the plain starting point, and boilerplate-vue sits beside it, so a Vue starter is part of the example set of a framework whose README describes it as belonging to the react community. The README does not explain what enables it or whether it is maintained.

Two more form a matched set: mf-host and mf-remote, which read as the two halves of a Module Federation arrangement. Nothing in the repository links them to each other, and no README line tells you whether federation is built in or assembled from those two examples.

Then there is the historical tail: legacy, max, ant-design-pro, antd-pro-create and create-umi-pro, alongside the current-looking create-umi-simple. Five of twenty-five examples are about where umi came from. No example directory carries a date, so working out which of them still reflects the v4 line is guesswork unless you open each one.

Three Jest configs, a turbo build, and duplicate script names

The repository has three separate Jest configurations: jest.config.ts, jest.e2e.config.ts and jest.turbo.config.ts. Coverage runs through `cov`, which is `jest --coverage`, and codecov.yml sits at the root. Builds go through `umi-scripts turbo build`, with `build:extra` alongside it.

The script table also carries duplicate pairs, which is worth knowing before you type a command from memory. `build:force` and `build:release` are the same string, `umi-scripts turbo build --no-cache`. `doc:build` and `docs:build` are the same string too, `pnpm --filter @umijs/docs build`. Two names, one behaviour, both still wired up.

Dependency bumps are deliberately manual: `dep:update` is `pnpm up --interactive --latest --recursive`, so nothing in the repository upgrades your dependencies without a person deciding to. Formatting is `prettier --cache --write .` with separate recipes for docs and plugin docs.

The codemod scripts run with their safety checks set to none

The codemod/ directory holds its own package, `@umijs/codemod`, with its own build and release scripts, and two of its run recipes set two environment variables to the string `none` before invoking anything: `codemod:run` and `codemod:test` both prefix `BACON=none GIT_CHECK=none`, with `codemod:run` going on to call `./codemod/bin/umi-codemod.js --cwd codemod/fixtures/tmp`.

Read plainly, the project runs its own codemod suite with the git check disabled, against a scratch directory under codemod/fixtures/tmp. That is a reasonable way to test a transform, and it means the path you would copy for your own upgrade is the one path that has been exercised with its guard off.

The directory itself is the answer to how umi expects upgrades to happen. Transforms live in the repository rather than in a written migration guide, and the README links a Contributing Guide at https://umijs.org/docs/introduce/contributing without mentioning them.

Three core maintainers, nine maintainers, and agent files in the root

The README defines its own tiers, which is more than most projects do. Core Maintainers are community members who have contributed significantly through addressing issues, fixing bugs and implementing enhancements or features: sorrycc, xiaohuoni and fireairforce. Maintainers are people with 10 or more merged PRs, or who have spent a lot of time on the community and on issues: PeachScript, YdreamW, yuaanlin, fz6m, stormslowly, xierenyuan, siyi98, txp1035 and zenotsai. Contributors need one merged PR, and joining the Contributor Group means contacting sorrycc.

Then the root directory. CLAUDE.md, a .claude/ directory, .cursorrules, TAKUMI.md and RULE.md are all committed, alongside CONTRIBUTING.md, SECURITY.md and a did-you-know/ directory. Whatever your editor or agent reads on open, this repository has committed a set of instructions for it.

Maintenance itself looks current. The repository is not archived and the last push was on 2026-10-31. Three releases landed in eleven days: v4.7.27 on 2026-10-23, v4.7.29 on 2026-10-31 and v4.7.30 on 2026-11-03, all on the v4 line that the launch post link points at.

Editorial conclusion

Adopt umi when you are willing to treat https://umijs.org/ as the real documentation, because the README in this repository will not tell you what the framework does, how to install it, or which bundler it uses. Do not judge it from the repository metadata either, since the description field contains a sentence that breaks halfway through. Verify two things before you commit: that examples/bundler-vite-demo or examples/bundler-webpack-demo matches your build, and that v4.7.30 from 2026-11-03 is the version you want rather than a range, given three patches in eleven days.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes