uView Pro: a TypeScript rewrite of uView for the uni-app and Vue 3 ecosystem

What it is: uView 1.8.8 rebuilt in TypeScript for Vue 3

uView Pro is a UI framework built for the uni-app ecosystem on Vue 3 and TypeScript, and the README explains the lineage precisely. The baseline version is based on uView 1.8.8, completely refactored using TypeScript, and the original uView UI is described as an excellent UI framework in the uni-app ecosystem whose components and tooling make the work easier.

So this is not a new design system. It is a port of an existing, widely used Chinese framework to a newer stack, which is a very different proposition from building components from scratch, and it explains both the breadth of the component set and the presence of a large body of documentation and examples that already exist for the original.

The rewrite targets the full platform spread. The README states that coverage includes Android, iOS, HarmonyOS and mainstream mini program platforms such as WeChat, Toutiao and Alipay, with one codebase running on multiple platforms, and that it supports a multi-theme system, dark mode and internationalisation.

The published component count is given in two places and differs slightly. The repository description says more than eighty high quality components, and the feature list says 70 plus curated components. The higher figure is the current one, since the description tracks the current state while the feature list is older prose.

The project is MIT licensed, the homepage is uviewpro.cn, the last push was on 2026-10-10, and the recent releases are v0.6.21 and v0.6.20 both on 2026-10-10 with v0.6.19 from 2026-09-07.

It is also published outside GitHub. The README links a Gitee repository, an AtomGit repository, an npm package named uview-pro, and a HarmonyOS app store listing, which is a distribution pattern typical of Chinese frontend ecosystems where npm alone is not the only channel.

The platform matrix, and the HarmonyOS angle

The supported platform list in the feature section is the most concrete thing in the README, and it is longer than the uni-app pitch usually suggests.

It covers Android, iOS, WeChat mini programs, H5, QQ mini programs, Baidu mini programs, Alipay mini programs and Toutiao mini programs. The build script list in the package.json goes further still, with separate dev and build targets for Alipay, Baidu, JD, Kuaishou, Lark, QQ, Toutiao, Weixin, Xiaohongshu and DingTalk mini programs, plus quickapp webview targets including a Huawei-specific one, and separate app targets for Android and iOS.

That matrix is the practical reason to use a framework like this. A product that ships a WeChat mini program, an Alipay mini program and an H5 site otherwise maintains three sets of components, and the whole point of uView Pro is that the component source is shared and the platform differences are handled by the build.

HarmonyOS gets its own section, and it is the one with the most product detail. The HarmonyOS app has been published to the Huawei HarmonyOS app store, providing a complete business scenario demo platform that includes the component library, template examples and scenario cases, with one-click copy and download to help developers get going. There is a system requirement: only HarmonyOS 5.0 and above devices are supported.

The project also has a call for input on the uni-app x version, with the README inviting suggestions on component priority, API design and breaking change strategy through a pinned discussions thread. That is worth noting because a rewrite targeting a new platform implies the component set and the API surface will change, and the project is asking for input before it happens rather than after.

Installation: npm or uni_modules, and the easycom rule

uView Pro supports two mainstream installation routes, npm and uni_modules, with a highly consistent configuration between them. The npm route is a normal package install:

npm install uview-pro

yarn add uview-pro

pnpm add uview-pro

The uni_modules route is different in kind. You go through the HBuilderX plugin marketplace or download it by hand and place uView Pro into the uni_modules directory of the project, so it lives inside the source tree rather than in node_modules.

Either way, the components are brought in automatically through easycom, and that is the piece that needs care. The rule goes in pages.json:

{
    "easycom": {
        "autoscan": true,
        "custom": {
            "^u-(.*)": "uview-pro/components/u-$1/u-$1.vue"
        }
    },
    "pages": []
}

The pattern means any component named u-something maps to the file at uview-pro/components/u-something/u-something.vue, so you use a component without importing it. The README carries three notes about this configuration that are worth reading before you start: after changing the easycom rules you need to restart HBuilderX or recompile the project, there must be only one easycom field in pages.json or you need to merge multiple rules yourself, and the rule must be placed inside custom or it has no effect.

The registration step in main.ts differs between the two installation routes, and the import path is the difference:

import { createSSRApp } from 'vue';
import uViewPro from 'uview-pro';

export function createApp() {
    const app = createSSRApp(App);
    app.use(uViewPro);
    return {
        app
    };
}

The uni_modules variant of that import is a path alias into the project directory rather than a package name, which is the only line that has to change when you switch routes. The global styles are then imported in uni.scss for the theme and at the top of App.vue for the base stylesheet, again with a different path per installation route.

The feature set, the on-demand imports and the tooling

The feature list in the README is written in a promotional register, but the individual claims map onto real capabilities.

On-demand imports and a smaller bundle are listed, which is the direct consequence of the easycom setup, since a component is only bundled when it is used. The list also claims a set of JavaScript helpers, a set of common pages and layouts, detailed documentation with modern demos, and the platform compatibility already covered above.

The multi-theme and dark mode support is described in the project overview as part of the core, alongside internationalisation, and the component naming convention makes it possible to guess a lot of the API. The prefix is u-, the same prefix the easycom rule matches on, so a component such as u-button or u-popup follows the naming pattern of the original uView library, which is a deliberate choice for anyone migrating an existing project.

The repository layout shows how a project of this type is put together. There is a src/ directory holding the component source, with a changelog referenced at src/uni_modules/uview-pro/changelog.md, and a scripts/ directory. There is an unpackage/ directory for build output, harmony-configs/ for the HarmonyOS target, an hbuilderx/ directory, and index.html and vite.config.ts at the root for the web build.

The tooling is worth noting because it is the toolchain a Chinese uni-app developer will already have. The package.json is a demo project, uview-pro-demo, and its scripts are all uni invocations, with one for each platform, plus an SSR variant for H5. There is a prebuild step that runs a script to update the date, and a postbuild step that runs a script to fix empty CSS, which is the kind of small platform-specific fix that only appears once you have built for every target.

The version pins in the README badges are also a signal: Node 18 or later and pnpm 7.30 or later, and the package-lock file is a pnpm lockfile, so the project expects pnpm even though it is also installable with npm or yarn.

The contribution rules, which are really a testing policy

The section on pull requests says the project is happy to accept good quality pull requests, but before that the author wants you to understand that uView Pro is a project that has to stay compatible across multiple platforms, covering mini programs, H5, iOS apps and Android apps, including both nvue pages and vue pages.

The request that follows is to test compatibility on as many of those platforms as you can before you fix a bug and submit, and preferably to include test screenshots to make review easier.

That is a heavier requirement than most component libraries impose, and the reason is specific to this ecosystem. A uni-app component is not just a Vue component. It compiles to different runtimes, mini program environments have their own rendering and no DOM, and nvue is a separate native rendering path. A change that looks correct in an H5 browser can be visibly broken in a WeChat mini program, and there is no single test run that tells you.

The repository tooling supports that policy in a practical way. There is a.copilot.md file at the root,.husky/ and a.lintstagedrc for commit hooks, a.czrc and.cz-config.js plus commitlint.config.js for conventional commits,.eslintignore and.prettierrc.js for linting, a.nvmrc for the Node version, and a.changelogrc.js for the changelog. There is also a separate README-pnpm.md with more running and build commands, and a README.en.md, so the project is maintained in Chinese with an English version alongside.

For a contributor, the practical takeaway is that a change is not finished when it works on the platform you have open. The author asks for screenshots from other platforms, and the.github directory may hold workflow configuration, though the README does not document what is checked automatically.

Editorial conclusion

Adopt uView Pro if you are building in the uni-app ecosystem and want one component set that covers H5, native apps and the Chinese mini program platforms with TypeScript types, dark mode and i18n included. Do not adopt it for a plain Vue 3 web application, since the easycom component resolution and the build pipeline are uni-app specific. Before you start, decide between the npm and uni_modules installation routes, because the import paths in the config differ, and test your changes on more than one platform before sending a pull request, which is what the project asks contributors to do.

Frequently asked questions

Official sources

1. anyup/uView-Pro on GitHub
2. License: MIT
3. Project website
4. README
5. Releases