Ant Design Mini: the Ant Design component library for Alipay and WeChat mini programs

What it is and where it sits

Ant Design Mini is a UI component library for Alipay mini programs that is also compatible with WeChat mini programs, and it follows the Ant Design specifications. The tagline is to explore the ultimate experience of mobile mini programs.

The framing matters because mini programs are a distinct platform. They are not web pages: they are single-page applications running inside a super-app with a restricted runtime, a custom rendering model based on template files rather than a DOM, and their own component and API model. A web UI library does not port to that, and a React library for the web does not either.

So the design has to be rewritten rather than adapted, and Ant Design Mini is the Ant Design design system rebuilt on the mini program model. The name carries the Ant Design lineage, and the repository sits in the ant-design organisation alongside the main Ant Design library, which is the point: the visual language should match, but the implementation follows the platform.

The four feature bullets describe the scope. A rich component library with a wide range of practical components, flexible customization and expansion, and components that are easy to choose and use. Customizable themes and international languages, with more theme styles and clean switching of component text in multiple languages. A design language and development framework, described as a full ecosystem for rapid application development. And multi platform support, covering Alipay, WeChat and uni-app, with separate adaptation guides for the WeChat and uni-app cases.

The primary language is TypeScript, the licence is MIT, the default branch is master, and the homepage is mini.ant.design, which carries both an English documentation site and a Chinese one, plus two service group links. The recent releases are 3.1.6 from 2025-02-26, 3.1.5 and 3.1.4 from 2025-02-20, and the last push was on 2026-10-16 with the project not archived. The package manifest carries a higher version, 3.4.3, which is the version of the source in the repository rather than the last published release.

Installing it, and the package name is not the repository name

The install is a single command, and the README lists all four common package managers:

$ npm install antd-mini
# or
$ yarn add antd-mini
# or
$ pnpm add antd-mini
# or
$ bun add antd-mini

One detail catches the eye: the package on npm is antd-mini, not ant-design-mini, and the repository is called ant-design-mini. The name is shortened for the registry, and the manifest confirms it, with the name field set to antd-mini. If you are looking for the package, search for antd-mini.

The topic list makes the same point, carrying antd-mini, mini-antui and mini-ali-ui alongside the longer names,

You can also try the components before installing, either by scanning the Alipay QR code in the README or by visiting the documentation site, which hosts live examples. For a component library, being able to see the actual behaviour on a device rather than only read the API table is a meaningful part of the evaluation, because mini program components often behave differently from their web equivalents in ways the documentation cannot convey.

The docs site is where the adaptation guides live, one for WeChat and one for uni-app, and those are the documents to read before you start if you are not building for Alipay. The compatibility story is a headline claim and the guides are where it is either confirmed or complicated.

The build pipeline, and the compiled WeChat output

The package manifest is where the engineering shows, and the scripts are unusual enough to be worth reading in full.

    "dev": "tsx ./scripts/dev.ts",
    "build:axml": "tsx ./scripts/compile-axml.ts",
    "transform": "tsx ./scripts/transform.ts",
    "generate": "tsx ./scripts/generate.ts",
    "dev:doc": "rimraf node_modules/.cache && node ./scripts/dev-doc.js",
    "build": "rimraf node_modules/.cache && npm run build:axml && node ./scripts/build.js",
    "deploy:docs": "npm run build && echo 'mini.ant.design' > ./docs-dist/CNAME && gh-pages -d docs-dist",
    "changelog": "auto-changelog -p --ignore-commit-pattern \"chore\\(release\\)\"",
    "prepublishOnly": "npm run build",
    "pub": "node scripts/publish.js",
    "test": "vitest run",
    "check-compiled": "tsx ./scripts/check-compiled.ts",
    "cov": "vitest run --coverage && tsx ./scripts/patch-coverage.ts",
    "local-pub:beta": "node scripts/quick-release.js beta",
    "local-pub:alpha": "node scripts/quick-release.js alpha",
    "local-pub:latest": "node scripts/quick-release.js latest"

The build step is rimraf the node_modules cache, then build:axml which runs scripts/compile-axml.ts, then node scripts/build.js. The separate AXML compilation is the interesting part. AXML is the template file format mini programs use, and it is not the same across platforms, so the library compiles its own templates into whatever the target platform expects.

That is the answer to how one library serves three platforms. Rather than maintaining three template sets, the source templates are compiled per platform, and the manifest declares where the result goes with a miniprogram field pointing at compiled/wechat/src.

So the WeChat build is a compiled artefact checked into the package. The miniprogram field tells the WeChat toolchain where to find the components, and the same published package serves Alipay, WeChat and uni-app.

Three more scripts support that. The dev script runs scripts/dev.ts with tsx, the transform script runs scripts/transform.ts, and the generate script runs scripts/generate.ts. The check-compiled script runs scripts/check-compiled.ts, which is the piece that tells you the most about how the project is maintained. A check on compiled output means the repository verifies that the committed WeChat build matches what the compiler produces from the current source, so the two cannot drift apart silently.

The release machinery is similarly thorough. There is a changelog script using auto-changelog with a pattern that ignores chore(release) commits, a pub script for publishing, and three quick-release scripts for beta, alpha and latest channels, each pointing at scripts/quick-release.js with a different tag. And prepublishOnly runs the build, so a published package always contains a fresh compile.

The test script is vitest run, with a separate cov script that runs coverage and then patches it through scripts/patch-coverage.ts, which suggests the coverage tooling needed adjustment to report correctly for this layout.

The dependencies, and what they reveal about the runtime

The dependency list is short and every entry tells you something.

@mini-types/alipay at about 3.0.5 provides the Alipay mini program type definitions, which is the equivalent of the DOM types in a web project. If you have written mini program code you will recognise the shape of the problem: there is no standard library of types, so the platform's API surface has to be declared.

@preact/signals-core at about 1.7.0 is the reactivity primitive, and this is a notable choice. A component library normally does not bring its own reactivity, but mini program frameworks are fragmented and the library needs a signal implementation that works across all of them, since the same component has to run under the Alipay runtime, the WeChat runtime and uni-app. A small signals core is a way to own that dependency rather than inheriting whichever one the host framework happens to use.

async-validator at about 4.0.7 is the form validation library, and dayjs at 1.11.7 handles dates, which matters because the mini program runtime has limited date handling and a component library needs consistent formatting across platforms.

Then there is a cluster of small utilities that all point in the same direction. lodash.filter, lodash.get, lodash.isfunction, lodash.kebabcase and lodash.reduce are individual lodash functions rather than the whole library, which is a deliberate trimming for a package that ships to mini programs where bundle size is a real constraint. fast-deep-equal at 3.1.3 does the same job for comparison. pinyin-firstletter gives the first letter of a Chinese name, which is a good clue about the primary audience: it is for search and sorting of Chinese-language content, which is where the majority of mini program users are. tslib at 2.5.0 is the TypeScript runtime helper.

The overrides block pinning get-func-name to 2.0.0 is a one-line dependency resolution fix, the kind of entry that appears when a transitive dependency causes a problem and the resolution is pinned rather than upgraded.

Taken together, the dependency list describes a library that takes bundle size seriously, ships without a framework of its own, and targets Chinese-language applications first.

The repository, and the documentation and tooling around it

The top-level listing is large and shows a project with real infrastructure.

The source lives in src/ with the tests in tests/ and demo/ holding a demo application with components/, pages/ and utils/ directories. The docs/ directory holds the documentation source, and .dumi/ with a .dumirc.ts is the dumi documentation site generator, which is the same tool Ant Design uses for its own docs.

The multi-platform build shows up as configuration files. There are tsconfig.json for the main build, tsconfig.alipay.demo.json, tsconfig.wechat.demo.json and tsconfig.wechat.json, so each platform and each demo target has its own compiler configuration. And there are two project configuration files, mini.project.json for the Alipay IDE and project.config.json for the WeChat one.

The linting setup is layered, which is what a large TypeScript project with mixed file types ends up with. There is an .eslintrc with an .eslintignore, a .prettierrc with a .prettierignore, and a .stylelintrc for the stylesheets, plus a .editorconfig. A stylelint configuration alongside eslint and prettier tells you the project has CSS of its own, not just styles carried over from the parent Ant Design library.

Two directories are unusual enough to comment on. There is a copilot/ directory and a copilot-demo/, which suggests the project ships a Copilot configuration and an example showing what it does. And there is a scripts/ directory holding the build, publish, release and verification scripts, several of which the manifest already showed.

The git hooks are configured in the manifest rather than in a file, with a pre-commit hook running lint-staged and a commit-msg hook running scripts/verifyCommitMsg.js. The commit message check is a convention-enforcement hook, and lint-staged runs eslint on staged TypeScript and JavaScript separately with the appropriate extension flag.

The typings/ directory and typings.d.ts handle the ambient type declarations, and the CHANGELOG.md at the root matches the auto-changelog script.

The overall impression is of a library that treats its own build output as a checked artefact, which is the only way a compiled multi-platform package can stay trustworthy.

How to evaluate it, and what to check first

There are four things to establish.

First, which platform you are actually targeting. The library claims Alipay, WeChat and uni-app support, but the WeChat build is a compiled artefact, and the adaptation guide for WeChat is a separate document from the main documentation. If your target is WeChat, read that guide before anything else, because the compilation step is where the differences live.

Second, whether the version you would install matches the source. The manifest is at 3.4.3 while the last published release is 3.1.6 from February 2025, and the last push was in October 2026. That gap is normal for a repository that publishes on its own schedule rather than from every commit, but it means the code in the repository and the code on npm are not the same thing, and the documentation site may describe either.

Third, the runtime constraints. Mini programs have package size limits and a restricted runtime, and this is why the dependency list trims lodash to single functions and why the library carries its own signals implementation. If you are near a size budget, that is the first thing to check, because a component library's own weight is a fixed cost against your limit.

Fourth, the design language question. This library follows the Ant Design specifications, so if your wider product is Ant Design on the web, the mini program side will look consistent. If it is not, you are adopting a design language along with the components, and the theming options are what let you adjust rather than accept it.

What you get is a component library built by the same organisation that maintains Ant Design, with a genuine multi-platform story that is implemented by compilation rather than duplication, and the tooling to keep that honest. For a team shipping the same product to Alipay and WeChat users, that is a substantial amount of work removed. The trade is the mini program platform's own constraints, and the fact that the two ecosystems are not quite the same, which is why the adaptation guides exist and why you should read the one for your platform rather than assume parity.

Editorial conclusion

Adopt Ant Design Mini if you are building for Alipay or WeChat mini programs and want components that match the Ant Design design language, particularly if you need the same product on both platforms and would otherwise maintain two component sets. Do not adopt it expecting the WeChat and uni-app support to be a straight drop-in, because those platforms are supported by compiling the templates and the README points to separate adaptation guides for each. Before you commit, read the guide for your platform, check the package size against the mini program limit since a component library's weight is a fixed cost, and confirm which version you are actually installing, because the repository manifest sits at 3.4.3 while the last published release was 3.1.6 in February 2025.

Frequently asked questions

Official sources

1. ant-design/ant-design-mini on GitHub
2. License: MIT
3. Project website
4. README
5. Releases