# Vue Mini: one npm create command and a README that points elsewhere

> vue-mini is a TypeScript monorepo behind a Vue 3 framework for WeChat mini programs, with the publishable code under packages/ and the tutorial on vuemini.org. What a new adopter gets from GitHub is one npm create command, a private root manifest, and a version line still sitting on a candidate.

**vue-mini/vue-mini** — A WeChat Mini Program framework based on Vue 3. Simple, powerful and high-performance.

- Repository: https://github.com/vue-mini/vue-mini
- Website: https://vuemini.org
- Stars: 2,083 · Forks: 90
- Language: TypeScript
- License: MIT
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/vue-mini-vue-mini

## npm create vue-mini@latest is the only command the README gives you

Vue Mini presents itself as a mini program framework built on Vue 3, and its entire install path fits on one line:

```bash
npm create vue-mini@latest
```

That is the whole short version the project offers. Past this command the page stops and sends readers to vuemini.org for the guide. No config key, no folder layout and no build command for a generated project appears anywhere in it. The repository does carry a `docs/` directory wired to VitePress, so the prose exists, just not in the file most people read first. A team comparing frameworks before installing anything will find fewer facts here than in the badge row at the top of the page.

## A private root manifest with the publishable code under packages/

The root package.json is marked `"private": true` and declares no dependencies at all, only devDependencies. That single flag explains the shape of the repository: `pnpm-workspace.yaml` and `pnpm-lock.yaml` sit at the top level, the publishable packages live under `packages/`, and the badge row points at `@vue-mini/core` on npm rather than at the repository itself. Reading the root manifest therefore tells you about the maintainer's toolchain, not about the framework you install.

Contributors clone the repository and work inside a pnpm workspace, while new users arrive through npm create. Two package managers meet at the same boundary, and only one of them is described for somebody who just generated a project. That manifest also declares version 1.2.16 at a time when the project tags newer candidates, a detail worth reading closely.

## node runs the build and publish scripts as plain TypeScript

The whole build surface is a handful of script names in the root manifest:

```json
"scripts": {
  "format": "prettier --check \"**/*.{js,cjs,ts,json,md}\"",
  "lint": "eslint .",
  "type": "tsc --noEmit",
  "test": "vitest",
  "build": "node build.ts",
  "release": "node release.ts"
}
```

node executes `build.ts` and the publishing script without a separate compile step, which is why `"type": "module"` is set at the root and why tslib 2.8.1 is on the list. Packaging runs through rollup 4.63.5 with `@rollup/plugin-typescript` 12.3.0 and `rollup-plugin-dts` 6.5.1 for declaration files, and `tsconfig.build.json` sits beside `tsconfig.json` so package output can use different compiler settings from the type check. For an adopter this block is noise: none of these scripts run inside a generated project, and none of them describe how your code reaches a mini program bundle. The documentation site has its own three commands instead:

```bash
vitepress dev docs
vitepress build docs
vitepress preview docs
```

Those belong to maintainers writing guides, not to the person who just generated an app.

## Where vitest, tsc and husky sit between a commit and master

Quality gates are configured once at the root rather than per package. Type checking runs as `tsc --noEmit` under the script named type, tests run on vitest with `@vitest/coverage-istanbul` behind the codecov badge, and eslint 10.11.0 runs with typescript-eslint 8.70.1 under `eslint.config.js`. Formatting is checked with prettier and enforced locally by husky 9.1.7 through the prepare hook, with `lint-staged.config.js` filtering staged files first.

The badge row points at an Actions workflow inside `.github/`, so the same checks run remotely as well. `global.d.ts`, `vitest.config.ts` and `vitest.setup.ts` sit beside the manifests, which means test setup is centralised rather than owned by each package under `packages/`. None of that is visible in a project you create, and the repository does not say what a generated project ships with. A team that wants a testing baseline will not find one described in this repository.

## The root manifest reads 1.2.16 while the newest tag reads 1.3.0-rc.4

Three dates in the project's own records run in an order a skim misses. The candidate 1.3.0-rc.3 was published on 2026-08-06, the stable 1.2.16 on 2026-09-25, and the next candidate 1.3.0-rc.4 on 2026-09-29, four days after the stable line moved. The root package.json still declares version 1.2.16, so the manifest on `master` does not describe the head of the 1.3 line.

Two consequences follow for anyone pinning a dependency. A team that wants 1.3 functionality has to take a candidate tag whose interface can still move between rc.3 and rc.4. A reader who treats the root manifest as the version reference sits a full minor line behind the tags. The last push landed on 2026-10-01, so the branch is current rather than abandoned.

## The performance claim is measured in a separate repository

The README makes a performance claim and then sends you elsewhere for the evidence. It states that the framework reaches parity with the native mini program frameworks and points at the mp-framework-benchmark repository, which is not part of this project. No measured figure appears anywhere in the vue-mini repository: no timing, no device list, no configuration, nothing to quote as a number. That benchmark project belongs to the same author named in the copyright line, so it reads as a comparison the project maintains for itself rather than an outside verdict.

Design history lives off the repository as well. There is a VueConf 2024 talk, A Mini Program Framework That Does Not Compromise, and a DeepWiki page at https://deepwiki.com/vue-mini/vue-mini for anyone who wants the architecture explained somewhere else. Understanding this framework therefore means leaving it, for the tutorial, the measurements or the history. Only the source stays put, and the source is the part with no onboarding notes.

## Adoption claims are self reported and the project has one maintainer

The user list is specific and it comes from one author. The page names NetEase, Tencent and internal use at WeChat, then lays out a table of fifteen mini programs as image files hosted on vuemini.org rather than as anything you can inspect in the repository. None of those apps ships source, a build or a link to a repository here, so the evidence is a name and a picture.

The same page states the project has been an individual effort since it began, with no company behind it, and routes funding through a sponsorship page. That concentration cuts both ways: one author means one decision maker on the API, and also no second maintainer if that person stops. The repository contains no governance document, no succession plan and no version support policy. On the legal side the answer is short: MIT is the licence, the copyright line reads 2019-present Yang Mingshan, and no additional terms are layered on top of it here.

## The alternative is the platform framework with no Vue layer

The comparison worth making is not between two Vue libraries; it is between Vue Mini and writing against the platform's own mini program framework, which is exactly what the benchmark in the header measures against. Going native gives you the host's templates, its own component model and its own API surface, with no compatibility layer in between and no second build system. Vue Mini takes the opposite trade and keeps Vue 3's reactive data and the composition API, then pays for it with a runtime that has to track Vue 3 itself inside a host that is not a browser.

That is the cost side of the choice, and the repository is thin on it. The README names no other framework, offers no migration notes from the native toolchain, and documents no upgrade path between the 1.2 stable line and the 1.3 candidates. Anyone crossing over has to learn the differences from the guide on vuemini.org.

## Conclusion

Vue Mini suits teams that already write Vue 3 and want the same composition API inside a WeChat mini program, and suits them less if they need a documented upgrade path or a benchmark they can verify from the repository, because the repository has neither. It is the wrong tool for a shop that wants two maintainers, a written migration guide, or a third party benchmark, since none of the three is in the repository. Before committing, run npm create vue-mini@latest, read the guide at vuemini.org, and compare the 1.3.0-rc.4 candidate against the 1.2.16 version a generated project would actually pin.

## FAQ

### How do I install Vue Mini and start a new project?

The only install command the README gives is npm create vue-mini@latest, which runs the project generator. Folder layout, build configuration and the rest of the tutorial are on vuemini.org rather than in the repository.

### Is Vue Mini actively maintained?

The last push to master landed on 2026-10-01 and the newest tag is 1.3.0-rc.4 from 2026-09-29, so the branch is current. The README does note that the project is an individual effort with no company behind it, so one person carries the maintenance load.

### What is the difference between Vue Mini and the native WeChat mini program framework?

Vue Mini lets you write a mini program with Vue 3 reactive data and the composition API instead of the platform's own templates and APIs. The README claims performance parity with the native framework and points to the mp-framework-benchmark repository for the comparison, without publishing numbers in this repository.

### Can I use Vue Mini in a commercial product?

The repository is MIT licensed, with copyright (c) 2019-present Yang Mingshan, and no additional terms are layered on top of it. Run your own review before shipping, since the project publishes candidates rather than a long stable line.

### Which version should I pin, 1.2.16 or 1.3.0-rc.4?

The root package.json still declares 1.2.16 while the newest tag is 1.3.0-rc.4, published on 2026-09-29 after 1.3.0-rc.3 from 2026-08-06. Choose the stable line if you want the interface fixed, and read the candidate notes on vuemini.org before taking a release candidate.

### Where do I report a bug or add my own mini program to the case list?

The README links to the vue-mini/vue-mini issues page, where new mini programs can be submitted for the case list. No other support channel, issue template or discussion forum is documented in the repository.

## Sources

- [License: MIT](https://github.com/vue-mini/vue-mini/blob/master/LICENSE)
- [Project website](https://vuemini.org)
- [README](https://github.com/vue-mini/vue-mini/blob/master/README.md)
- [Releases](https://github.com/vue-mini/vue-mini/releases)
- [vue-mini/vue-mini on GitHub](https://github.com/vue-mini/vue-mini)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vue-mini-vue-mini