unibest: a uni-app template that doubles as its own scaffolding CLI

One repository that is both the template and the CLI

The README describes the project as a uni-app development template built from uni-app, Vue 3, TypeScript, Vite, UnoCSS, wot-ui and z-paging, developed in VS Code rather than HBuilderX, and it states plainly that this repository is both the base template and the source repository for the CLI scaffolding tool. Those are two different products that happen to share one git history, and the consequences show up in the tree.

The repository structure section spells it out. The main repository on the `main` branch contains `packages/`, which holds the CLI scaffolding tool published to npm, and `src/`, which holds the template source that lives on the `base` branch. The CLI pulls base code from the base branch. So the file you read in `src/` on `main` is not necessarily the file that ends up in your project, because the CLI fetches it from `base`.

The generated project is a different shape. It has `src/` for source, `pages.json` for page configuration, `manifest.json` for application configuration, `App.vue` as the application entry and `main.ts` as the entry file, plus its own configuration files. The README is explicit that a user project does not include the `packages/` directory, which is how you can tell at a glance whether you are looking at the template repository or something generated from it.

The npm package name is `create-unibest` and it is published from `packages/cli/`, after which it clones the template from the Git main branch. The root `package.json` declares `workspaces` of `packages/*` and a `packageManager` of pnpm 10.10.0, and there is a `pnpm-workspace.yaml` in the tree, so the monorepo is pnpm-native rather than configured for npm or yarn.

The project moved, and the old address will not merge anything

The most operationally important paragraph in the README is a warning. The author cannot get into the old `codercup` address anymore and cannot retrieve the stars from it, so the badges show both addresses for historical reasons, but pull requests and issues are asked to use the new `feige996` address, because otherwise they cannot be merged.

That is a small thing with real consequences for anyone evaluating the project. The repository slug is still `codercup/unibest` and the `package.json` carries both, with `repository` pointing at the new address and a `bugs` object holding the new issues URL alongside `url-old` pointing at the old one. So the code is effectively maintained at `feige996/unibest` while the copy under review sits at `codercup/unibest`, and the two may not be identical. If you are going to use this template, clone the new address. If you are reading this repository to judge the project, that split is worth remembering before you compare anything.

The README also points to documentation at unibest.tech and a separate demo site, and the `homepage` field in `package.json` points at the same documentation URL. Note that the older field named codercup.github.io is what the repository's `homepage` metadata records, which is one more sign that some fields lag behind the move.

Four ways to create a project, including feature flags

There are four documented paths, and the interesting one is the second. The recommended path is to install the CLI globally and create a project:

pnpm add -g create-unibest
pnpm create unibest my-project
cd my-project
pnpm install
pnpm dev

The second path passes feature flags at creation time, either interactively or directly on the command line, with `i18n` and `login` as the two named features:

pnpm create unibest my-project --i18n --login

The third path adds the same features to a project that already exists, which is the one that matters most for a codebase you have already started:

pnpm create unibest add i18n login

The fourth path is cloning the repository directly and treating it as a template, which is the fallback when the CLI is not cooperating:

git clone https://github.com/feige996/unibest.git my-project
cd my-project

That feature flag design is the part worth copying regardless of whether you use this template. Adding i18n or a login strategy as a CLI operation means the wiring is written by the person who knows how the template wires things, rather than assembled by you from documentation that is one version behind. The cost is that you are taking someone else's opinion on what a login module should contain, and the generated code becomes yours to maintain.

Dev and build targets, and the HBuilderX escape hatch

The run section is organised by platform and each line names a script and a destination. For web it is `pnpm dev:h5` and then a browser at `http://localhost:9000/`. For WeChat it is `pnpm dev:mp`, then import `dist/dev/mp-weixin` into the WeChat developer tools. For apps it is `pnpm dev:app`, then import `dist/dev/app` into HBuilderX and run to a simulator, or to an Android or iOS base.

The build side mirrors it: `pnpm build:h5` writes to `dist/build/h5` and can be served by nginx, `pnpm build:mp` writes to `dist/build/mp-weixin` for upload through the WeChat developer tools, and `pnpm build:app` writes to `dist/build/app` for cloud packaging through HBuilderX. One configuration note is worth catching early: if the web build will not sit at the domain root, the `h5.router.base` property in `manifest.config.ts` is what you change.

The HBuilderX dependency is partial rather than total, which is the interesting part. For Android and HarmonyOS the README says you can import the entire unibest project into HBuilderX and run from its menu, rather than going through the generated `dist` folder. So the template reduces your dependence on HBuilderX for day to day work while keeping it as the packaging tool for the platforms that need a native base.

The scripts in `package.json` fill in the detail. There are `dev`, `dev:h5` and `dev:app` entries that all invoke `uni`, with `test` and `production` modes for each and an `dev:h5:ssr` variant that passes `--ssr`. There are platform-specific entries such as `dev:app-android`, `dev:app-ios` and `dev:custom`. A `preinstall` runs `npx only-allow pnpm`, so npm or yarn installs fail deliberately, and `prepare` runs husky init plus a script that creates base files.

Nine platforms in the compatibility table

The compatibility table is a single row of ticks and it covers more ground than most templates of this kind. The listed targets are H5, iOS, Android, the WeChat mini program, the ByteDance mini program, the Kuaishou mini program, the Alipay mini program, the DingTalk mini program and the Baidu mini program, and every one of them is ticked.

Two caveats follow immediately, one of them from the project itself. The README notes that each UI framework supports different platforms and points you at the individual UI framework's own site for details, which matters because wot-ui, UnoUI and the other component options do not have identical platform matrices. The tick row describes the template's routing and build layer, not every component you might add.

The list also tells you what this template is for. Six of the nine targets are mini program platforms, which are common in the Chinese market, so the platform spread is a deliberate audience choice rather than an accident. If your target is a single mobile app with no mini program presence, most of that row is not useful to you, and a plain Vue 3 plus Vite setup would be less machinery for the same result.

The UI layer is also where the repository's own text disagrees with itself. The README body lists Vite 5 with wot-ui and z-paging, while the repository description recorded alongside the project lists Vite 4 with UnoCSS and UniUI. Both cannot be current. The `vite.config.ts` and `uno.config.ts` files in the tree tell you which one is real, and they are the files to trust over any badge or blurb.

Where the stated versions disagree with each other

The environment section of the README says node 18 or higher, pnpm 9 or higher, Vue official 3.4 or higher, and TypeScript 5.0 or higher. The badge row above it claims node 18 and pnpm 7.30. The `package.json` says something different again, with `engines` requiring node 20 or higher and pnpm 9 or higher.

That is three sources and two answers for the Node floor, and the `package.json` field is the one your package manager will actually enforce. A third data point confirms which one is authoritative: the tree contains an `.nvmrc`, which is what a project pins its Node version in, and a `preinstall` that hard-fails anything other than pnpm. Where prose and machine-readable configuration disagree, the machine-readable configuration is the one that runs.

The versioning scheme is also worth understanding before you depend on it. The root `package.json` carries the template version in two fields, `version` and `unibest-version`, both at 4.4.0, plus an `unibest-update-time` field of 2026-04-25. There are no published releases, so a generated project has no changelog to read and no tag to compare against. What you have instead is a CLI that can add features to an existing project, which is the more useful half of the update story and the reason a version field alone is tolerable.

The rest of the tree is conventional for this kind of project. There is a `docs/` directory, `env/` for environment definitions, `scripts/` for the build and bump-version scripts, `vite-plugins/` for local Vite plugins, `pages.config.ts` and `manifest.config.ts` as the two configuration entry points, `openapi-ts-request.config.ts` for generated API types, `eslint.config.mjs` for linting, `.commitlintrc.cjs` and `.husky/` for commit hooks, and both `.changeset/` and an `AGENTS.md`. There are also editor directories for `.vscode/`, `.cursor/` and `.trae/`.

Editorial conclusion

unibest is a reasonable answer to a specific question, which is how to start a uni-app project without HBuilderX as your only editor. What it gives you is a working Vite and pnpm setup with routing, layout, request wrapping, login interception, UnoCSS and i18n already wired, plus the option to add features at scaffold time rather than by hand. What it is not is a framework with an API of its own: everything it ships is either uni-app, Vue 3, or a selected third-party library, and the value is in the choices and the wiring rather than in anything unibest-specific. Two things deserve a decision from you rather than an assumption. The repository moved from `codercup` to `feige996`, and the old address cannot be used for issues or pull requests, so point your tooling at the new one. And the version numbers disagree with each other, so read `package.json` rather than the badge row. The last push was on 2026-03-28 and there are no published releases, so version tracking is by the `unibest-version` field. Start with `pnpm create unibest my-project`, then read `manifest.config.ts` and `pages.config.ts` in the generated project.

Frequently asked questions

Official sources

1. codercup/unibest on GitHub
2. Issues
3. License: MIT
4. Project website
5. README