# vue-element-plus-admin v3: a Vue 3 admin starter built around server-driven routes

> ElementAdmin v3 keeps the infrastructure an admin app needs (dynamic routes, layouts, CRUD hooks, request client) and drops the demo-page bulk. This review covers the workspace layout, the route contract, the install path and where the template stops.

**kailong321200875/vue-element-plus-admin** — A backend management system based on vue3, typescript, element-plus, and vite

- Repository: https://github.com/kailong321200875/vue-element-plus-admin
- Website: https://element-plus-admin.cn/
- Stars: 3,696 · Forks: 870
- Language: Vue
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/kailong321200875-vue-element-plus-admin

## What vue-element-plus-admin v3 actually ships

Most Vue admin templates sell themselves on the number of pages they include. ElementAdmin v3 goes the other way. The README describes it as "a lean, extensible Vue 3 admin starter for real-world applications" and says it focuses on stable infrastructure rather than a large collection of demo pages. The capabilities it keeps are the ones every admin application needs: session recovery, server-driven routes, layouts, TagsView, requests, forms, CRUD state, themes and internationalization. Business UI and domain models are left to the application.

The intended reader is a team starting a Vue 3 back-office project that already has, or plans to have, its own API for menus and permissions. The template assumes that assumption explicitly: only the root layout, login, redirect and error shell routes are static, and everything else arrives from the API after authentication. If your navigation is fixed at build time, the central mechanism of this project is dead weight.

The stack is Vue 3.5, Vite 8, TypeScript, Element Plus 2, Vue Router 5, Pinia 4, Vue I18n 11, UnoCSS, Axios and ECharts 6, with VitePress 1 for the documentation app and Oxlint, Prettier and Stylelint for checks. The licence is MIT.

## The dynamic route contract and why it shapes the whole template

The most consequential design decision here is that the frontend does not hold a second, role-filtered route table. After login, the API returns the complete route tree available to the current user, and the application registers it at runtime. The README gives a small table for the component field, and it is worth reading as a contract rather than a convenience:

```text
#                        Admin Layout
##                       Route group without a page component
views/Dashboard/Analysis  Page under apps/admin/src/views
```

A single hash means the route renders the Admin Layout. A double hash means a grouping node with no page of its own, useful for nesting menus without an extra component. A path such as views/Dashboard/Analysis resolves to a file under apps/admin/src/views. Two constraints follow from this and the README states both: route icons must be registered by the consuming app, and route names must be globally unique. The development conventions repeat the point from the other side, telling contributors to keep route metadata, locale keys and the app icon registry synchronized with the backend route contract.

That last sentence is the real cost of the design. Authorization logic moves to the server, which is usually where you want it, but the frontend now has three registries that must agree with whatever the backend emits: route names, icon names and locale keys. Nothing in the README describes a validation step that catches a mismatch at build time. A route whose icon is not registered, or whose name collides with another, is a runtime problem you discover in the browser.

The four layouts (classic sidebar, top navigation, mixed navigation and dual sidebar) all read from the same route tree, so switching layout does not mean maintaining a second menu definition. Below 768px the desktop layouts fall back to a mobile sidebar automatically, per the README.

## Installing vue-element-plus-admin and reaching the first screen

The requirements are stated plainly: Node.js `^20.19.0 || ^22.13.0 || >=24.0.0`, pnpm `>=9.5.0` with `pnpm@9.15.3` pinned by the repository, and Git. Clone the master branch, install, and start the Admin app:

```bash
 git clone --branch master --single-branch https://github.com/kailong321200875/vue-element-plus-admin.git
 cd vue-element-plus-admin
 pnpm install
 pnpm dev:admin
```

The README states that Admin runs at http://localhost:4000/ by default, and that the built-in credentials are username `admin` and password `admin`. Those credentials belong to the bundled Mock API, which runs through the development mock server locally. You should land on the admin shell with the mock data already populated, which is enough to walk the layouts and the TagsView behaviour.

The mock layer has a second mode worth knowing about. When `VITE_USE_MOCK=true`, production builds include the browser-side mock adapter as well, so the static demo stays usable without a backend. That is a deliberate choice for the hosted demo, but the same flag in your own build ships mock data to users. Check it before you deploy.

Package-level tests are filtered rather than global, which tells you where the authors expect logic to live:

```bash
pnpm --filter @vea/hooks test
pnpm --filter @vea/request test
```

The full command list also includes `pnpm build:admin`, `pnpm build:admin:dev`, `pnpm build:admin:test`, `pnpm preview:admin`, `pnpm typecheck`, `pnpm lint`, `pnpm format:check` and `pnpm style:check`. The documentation app runs separately with `pnpm dev:docs` at http://localhost:4002/ by default.

## The pnpm workspace boundary, and where it currently stops

The repository is a pnpm workspace with two applications and four packages. Under apps there is admin and docs. Under packages there are components for small cross-app UI primitives, hooks for the UI-independent useCrud and useForm, request for a business-independent Axios client, and styles for shared reset and theme variables.

The README is candid about the packaging state: the packages currently export workspace source code and are compiled by each Vite application, and they are not prebuilt npm packages. So the separation is a source-level boundary, not a distribution boundary. You get the discipline of not importing application code into shared modules, and you do not get a versioned artefact you can publish or share with a second repository without copying it. Teams that want to reuse these hooks across two separate products should plan for that gap.

The conventions section makes the boundary a rule rather than a suggestion: business APIs and models go in apps/admin, shared packages must not import application code, and code is added to packages only after it has a stable, application-independent contract. That is a reasonable bar, and it is also the reason the packages are small. If you were hoping for a ready-made table wrapper or search form component, the README says the opposite: the UI layer is deliberately lean, with no BaseButton and no configuration-heavy Table, Search, Dialog or Detail wrappers. You write those.

## Icons, locales and the offline constraint

Two smaller decisions carry real operational weight. The first is icons. Each app statically registers only the Iconify icons it uses, and the README states that production does not depend on a CDN. That removes a network dependency and a class of outage, at the cost of a manual registry that has to stay in step with the route tree coming from your API. It is the same synchronization problem as route names, seen from a different angle.

The second is locale and theme switching. Vue I18n, Element Plus, the document language and persisted state are kept synchronized, and the README describes the switch as instant. The mechanism is not spelled out in the README beyond that synchronization claim, so treat the persisted-state behaviour as something to verify against your own storage and SSR assumptions rather than something documented in detail.

Element Plus components are imported explicitly and their styles are added on demand during the build. That is different from a global registration approach, and it means adding a component is a two-step action: import it, and make sure its styles are pulled in. The README does not describe a fallback for a component that renders without its styles, so this is a place where a missing import shows up as a visual defect rather than an error.

## Where this template is the wrong tool

The clearest failure mode is a project with no backend route service and no intention of building one. If your menus are static, the dynamic route registration adds a contract, three synchronized registries and a runtime failure mode in exchange for nothing. A template with static routes and a large page library would serve you better.

The second is the mock flag. Because `VITE_USE_MOCK=true` pulls the browser-side mock adapter into a production build, a build pipeline that sets it globally will ship mock responses. The README presents this as the reason the static demo works without a backend, which is true, but it is also a switch that has to be handled per environment.

The third is the packaging boundary. The packages are consumed as workspace source. If your organisation needs to share the request client or the CRUD hooks across repositories, or publish them, this repository does not give you a prebuilt artefact and the README does not describe a publishing path.

Finally, the documentation split deserves attention. The README states that the former site at element-plus-admin-doc.cn documents the legacy architecture, and that new projects should use the v3 documentation and current branch code. Search results and older tutorials still point at the legacy site, so a team following an old guide can end up reading architecture notes that no longer match the branch. Version 3.0.0 shipped on 2026-08-27 and 3.1.0 on 2026-09-01, so the v3 line is recent; the last push to the repository was on 2026-09-01.

## Alternatives and the difference in approach

The closest comparison in the search data is vue-pure-admin, another Vue 3 admin project. The distinction that matters here is not the component library but what the template is willing to own. vue-element-plus-admin v3 deliberately excludes business UI, ships no BaseButton and no configuration-heavy Table, Search, Dialog or Detail wrappers, and pushes business APIs and models into apps/admin. A template that bundles those wrappers gives you more code on day one and more decisions already made for you, and it also gives you more code to unwind when your requirements diverge from the wrapper's assumptions.

Vue3-element-admin is the other name that appears alongside this project in searches. Both target the same audience of Vue 3 back-office developers, and the meaningful question to ask of either is where the route tree comes from. If the template registers menus at build time, its permission model lives in the frontend and your API only supplies data. Here the API supplies the route tree itself, and the frontend registers it at runtime.

On the tooling side, the choice of Oxlint over ESLint is stated as a convention: use Oxlint instead of adding ESLint configuration. That is a smaller decision than the routing model, but it is the kind of thing that generates friction if your team already has ESLint plugins it depends on. Commits are checked by Husky, vue-tsc, lint-staged and Commitlint, with Conventional Commit messages expected.

## Maintenance, licensing and what to check before adopting

The repository is not archived, and the last push was on 2026-09-01. Release history shows a long gap: v2.10.0 on 2025-01-09, then v3.0.0 on 2026-08-27 and v3.1.0 on 2026-09-01. The v3 line is therefore young, and the two v3 releases landed within a week of each other. A team adopting v3 should read the CHANGELOG.md and release notes for the v3.0.0 break rather than assuming v2 guides still apply, especially given that the legacy documentation site is still online and still indexed.

Upgrade cost is shaped by the workspace split. Because packages are consumed as source rather than as published versions, a change inside packages lands in your application the moment you pull, with no version boundary to hold it back. That is convenient during development and less convenient when you want to take a security fix in the request client without taking a change in the hooks. Pinning a commit or a tag is the practical answer, and the repository does tag releases.

The licence is MIT, which is permissive and permits commercial use and modification. That is a statement about the licence identifier in the repository, not legal advice; your own obligations around attribution and any third-party dependencies should be checked by whoever handles licensing on your side. The README does not discuss dependency licence auditing.

## Conclusion

Use vue-element-plus-admin v3 when you want a Vue 3 and Element Plus shell whose route tree comes from your API and whose shared packages stay free of application code, and when you are willing to write the business UI yourself. Do not adopt it if you need a backend, a database or a finished product: the repository ships a mock API for local development and a browser-side mock adapter for the static demo, nothing more. Before committing, verify three things in the repository: that your Node and pnpm versions satisfy the stated ranges, that your backend can return the route tree the component contract expects, and that your team accepts Oxlint and Commitlint as part of the workflow.

## FAQ

### Is Element Plus free to use with vue-element-plus-admin?

The repository's own licence is MIT, which is permissive and permits commercial use and modification. Element Plus is a separate dependency listed in the tech stack, and the README does not discuss dependency licence auditing.

### What is Vue used for in a project like vue-element-plus-admin?

In this repository Vue 3.5 is the framework the admin application is written in, paired with TypeScript, Vite 8, Element Plus 2, Vue Router 5, Pinia 4 and Vue I18n 11. The README describes the result as a Vue 3 admin starter focused on stable infrastructure rather than demo pages.

### Is vue-element-plus-admin a good free Vue admin template?

It is MIT licensed and free to use. Whether it fits depends on your routing model: only the root layout, login, redirect and error shell routes are static, and the rest of the route tree is returned by the API and registered at runtime, so a project with build-time menus gets little from the central mechanism.

### What is the purpose of an admin dashboard such as vue-element-plus-admin?

The README frames it as infrastructure for back-office applications: session recovery, server-driven routes, four layouts, TagsView, requests, forms, CRUD state, themes and internationalization. Business UI and domain models are deliberately left to each application.

## Sources

- [kailong321200875/vue-element-plus-admin on GitHub](https://github.com/kailong321200875/vue-element-plus-admin)
- [License: MIT](https://github.com/kailong321200875/vue-element-plus-admin/blob/master/LICENSE)
- [Project website](https://element-plus-admin.cn/)
- [README](https://github.com/kailong321200875/vue-element-plus-admin/blob/master/README.md)
- [Releases](https://github.com/kailong321200875/vue-element-plus-admin/releases)

---

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