vue-pure-admin: an ESM-first Vue 3 admin template and when to use the thin build instead

What vue-pure-admin solves, and who it is actually for

Starting a Vue 3 admin console from an empty Vite project means rebuilding the same furniture every time: a layout with sidebar, header and tab bar, a route guard, a permission model, a request wrapper, a theme switcher, a mock layer, and a set of CRUD pages that prove the wiring works. vue-pure-admin ships that furniture as a template. The README describes it as an open source, free, out-of-the-box mid and back office management system template, written and organised entirely under the ECMAScript module specification, using Vue3, Vite, Element-Plus, TypeScript, Pinia and Tailwindcss.

The audience is narrower than the description suggests. This is for frontend engineers who already know Vue 3 and the Composition API and want a reference implementation they can cut down, not a framework that hides Vue from them. The repository contains mock/, locales/, build/ and types/ directories alongside src/, which tells you it is a working application with its own conventions, not a library with a stable public API. If your team has not settled on Vue 3 yet, the template's opinions will be a cost rather than a saving.

One point the README makes early and plainly: for actual project development, use the reduced version. The full repository is the showcase; pure-admin-thin is the extraction of it, with the main functionality kept and two variants available, non-i18n and i18n. That distinction matters more than any feature list on this page.

How the ESM-only structure and Pinia state layer fit together

The package.json sets "type": "module" at the top level, so every .js file in the repository is parsed as an ES module. There is no CommonJS fallback path and no dual build. That single line explains most of the project's shape: Vite can treat the whole codebase as native ESM during development, and the build step does not need a compatibility shim for require().

The runtime stack is visible in the dependency list. Element-Plus supplies the component layer, Pinia supplies state, Tailwindcss supplies utility styling, and Vue Router drives navigation. The repository keeps its Vite configuration in vite.config.ts with a separate build/ directory for the parts of the config that are split out, which is a common pattern when a config file grows past a few hundred lines. Environment values live in three files: .env, .env.development and .env.staging, plus .env.production. The scripts reference those modes directly, so build:staging runs vite build --mode staging while the default build runs the production mode and then executes generate-version-file.

The Pinia store is the part most teams will touch. Because the project is ESM-only and TypeScript-first, stores are imported as modules rather than registered through a global install call, which keeps tree shaking meaningful. The trade-off is that nothing is injected for you at runtime. If you copy a store file into another project, you also copy its imports and its type dependencies. There is no plugin boundary that would let you take the state layer without the rest.

Two scripts reveal the intended workflow. The dev script runs vite with NODE_OPTIONS=--max-old-space-size=4096, and the build script raises that to 8192. Those flags are a signal about the size of the dependency graph rather than a claim about speed: the maintainers found it necessary to give Node a larger heap for this project to build cleanly.

Installing vue-pure-admin and running a first real page

The README offers a scaffold as the recommended path. Installing @pureadmin/cli globally and running pure create starts an interactive template selection, which is the route the project prefers because it lets you pick the thin variant at creation time rather than deleting files afterwards.

npm install -g @pureadmin/cli
pure create

If you would rather work from the repository itself, clone it and install with pnpm. The package.json enforces this: its preinstall script runs npx only-allow pnpm, so an npm install or yarn install will be rejected before dependencies are resolved. There is also a pnpm-workspace.yaml at the repository root.

cd vue-pure-admin
pnpm install
pnpm dev

After pnpm dev, Vite prints a local URL in the terminal; the README does not state the port, so read it from the output rather than assuming one. The .nvmrc file pins a Node version, and the Dockerfile uses node:20-alpine, both of which are worth checking before you install.

For a container build, the Dockerfile is a two-stage setup. The first stage enables corepack, activates pnpm, sets the npm registry to registry.npmmirror.com, installs with --frozen-lockfile, and runs pnpm build. The second stage copies /app/dist into nginx:stable-alpine and exposes port 80.

docker build -t vue-pure-admin .
docker run -dp 8080:80 --name pure-admin vue-pure-admin

The README states that after those two commands you open http://localhost:8080 to preview. Note the registry line in the Dockerfile: the image build pulls packages from a China-based mirror. If your build environment cannot reach it, that layer is the one to change, and changing it is a fork of the Dockerfile rather than a supported option.

The full template is a demo, and the thin version is the product

The clearest limitation is stated by the project itself. The README says the reduced version is what you should use for actual project development, and that it is extracted from vue-pure-admin, keeps the main functionality, and stays permanently in sync with the full version. Two variants are offered, non-i18n and i18n. The README gives bundle figures for the thin build: under 2.3MB after build with element-plus imported globally, and under 350kb when brotli compression is enabled and a CDN replaces the local libraries.

Those numbers describe pure-admin-thin, not the repository you are reading about. That is the trap. A team that clones vue-pure-admin, keeps the demo routes, the mock handlers and the example pages, and then measures its own bundle will not see those figures, and the README does not publish an equivalent figure for the full template. The full repository is a catalogue of what the template can do, and every catalogue entry is code you now own.

A second limitation is the missing backend. The project is a frontend template; the README documents no server, no authentication service and no database. The mock/ directory stands in for an API during development, and the environment files exist so you can point the app elsewhere, but the contract between frontend and backend is yours to define and yours to keep in sync.

Upgrade cost follows from the same structure. Because the template is a private package ("private": true) rather than a published dependency, you do not run a package manager upgrade to move to v7.0.0. You diff. The repository keeps CHANGELOG.md, CHANGELOG.zh_CN.md and CHANGELOG.en_US.md, and the release history shows v6.2.0 in October 2025, v6.3.0 in December 2025 and v7.0.0 in April 2026, so the cadence is a few releases a year. Each one is a merge you perform by hand against code you have already modified.

vue-pure-admin compared with Vue Vben Admin and Naive UI Admin

The two names that come up alongside this project are Vue Vben Admin and Naive UI Admin, and the difference is not cosmetic. vue-pure-admin is built on Element-Plus and Tailwindcss, and its README organises the whole pitch around that combination plus an ESM-only codebase. Vue Vben Admin is a separate project with its own component and styling choices; if your team has already standardised on Element-Plus, switching to Vben means retraining on a different component API and rewriting the parts of your UI that depend on Element-Plus props and slots.

Naive UI Admin takes the same divergence one step further by building on Naive UI, which is a component library with a different design language and a different TypeScript surface from Element-Plus. The migration cost between these templates is dominated by the component library, not by the router or the store, because Pinia and Vue Router are common ground across all three.

The comparison that actually matters for adoption is internal to this project: vue-pure-admin against pure-admin-thin. Same maintainers, same organisation, same release line, different amount of code. The thin version is the answer to the question "how much of this template do I want to delete?" and the README's recommendation is to start there. The full version is worth cloning when you want to read the implementation of a feature before deciding whether to bring it across.

There is also tauri-pure-admin and electron-pure-admin, which the README links as separate repositories. Those are desktop shells around the same frontend, not additional features of this one.

Licence, contribution rules and what the MIT terms leave open

The repository is MIT licensed, and the LICENSE file sits at the root. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive starting point, but it is a licence for the code, not for the project's identity: the README links a separate page for advanced services, and the MIT grant does not extend to any trademark or support arrangement. This is a description of what the licence text says, not legal advice; if you are embedding the template in a product with its own compliance review, run the LICENSE file past whoever handles that.

Contribution follows a conventional pattern. The README asks for an issue or a pull request, with the git flow spelled out: fork, create a branch named feat/xxxx, commit with a message like feat(function): add xxxxx, push, and open the pull request. Commit messages follow the Angular convention, and commitlint.config.js enforces it at commit time through the .husky/ hooks installed by the prepare script.

Linting is not optional in this repository. The lint script chains lint:eslint, lint:prettier and lint:stylelint, and the eslint invocation passes --max-warnings 0, which means a warning fails the command. If you fork and keep the hooks, expect your first commit to run through all three. If you do not want that, remove the husky prepare step deliberately rather than discovering it mid-commit.

Editorial conclusion

Adopt vue-pure-admin if you want a Vue 3, Vite and Element-Plus starting point where the ESM-only structure and the Pinia store layout are the point, and if you are willing to strip demo pages yourself. Do not adopt it if you need a backend, an authorization service or a component library you can upgrade independently of the template, and do not treat the full repository as your application skeleton: the README directs real projects to pure-admin-thin. Before committing, verify that pnpm is available (the package.json preinstall script runs npx only-allow pnpm), read the .env.development and .env.production files to see which variables your environment must supply, and confirm that the mock/ directory is disabled or removed before you point the app at a real API.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. pure-admin/vue-pure-admin on GitHub
4. README
5. Releases