RuoYi-Vue3: the frontend half of a framework most people mistake for a template

This repository has no backend in it

The single most important thing about this repository is what it is not. The GitHub description names Spring Boot, Spring Security and JWT, which sounds like a full-stack permission system. It is not. The README states plainly that this repository is the frontend stack, built on Vue 3, Element Plus and Vite, and that the matching backend code lives in separate repositories.

That boundary shows up in the package manifest too. `package.json` describes the project as an admin system, names it `ruoyi`, sets version 3.9.2, declares MIT, and points its repository field at a different project's repository URL on another host entirely. The runtime dependencies are the frontend half of a permission admin: `axios` for HTTP, `pinia` for state, `vue-router` 4 for routing, `element-plus` for components, `echarts` for the monitoring screens, plus `jsencrypt` for RSA-encrypted password submission and `nprogress` for the route loading bar.

The tree confirms it. There is `src/`, `html/`, `public/`, `bin/`, a `vite.config.js`, a `vite/` directory, three environment files named `.env.development`, `.env.production` and `.env.staging`, and no Java source anywhere. Cloning this alone gets you a dev server and an empty login form.

The three environment files are the interesting part of that list, because they correspond to the three build modes the scripts expose: a plain `vite` dev run, `vite build` for production, and `vite build --mode staging` for a test environment.

Three frontends, one repository, and a deliberate choice

The README contains a comparison table of the three evolution lines of this frontend, and it is the most decision-relevant thing in the file.

The original line runs Vue 2 with JavaScript, Vue CLI, Element UI, Vuex and Vue Router 3. Its selling point is stability and the volume of community material available, with the note that maintenance focus has moved elsewhere. The Vue 3 line in this repository runs Vue 3 with JavaScript, Vite, Element Plus, Pinia and Vue Router 4, described as the officially recommended active version with a modern stack and better development experience and performance. The third line is Vue 3 with TypeScript on the same stack, positioned for enterprise work with multiple contributors, on the argument that types reduce communication cost and give you hints while you code.

All three are maintained in parallel. That is the important operational fact: the choice is not migration, it is selection, and picking the wrong one leaves you behind on a line that still receives fixes but not new capability.

The README's own positioning lines up with the code generator claim. A code generator that emits JavaScript and TypeScript is only worth having if it can emit both, and that dual support is the main functional difference between line two and line three. If your team is more than a couple of people, the TypeScript line is the one the README points at.

Running it takes four commands and a Chinese mirror registry

The run instructions are short enough to quote in full, and the comments are part of the value here because they are the project's own.

# 克隆项目
git clone https://github.com/yangzongzhuan/RuoYi-Vue3.git

# 进入项目目录
cd RuoYi-Vue3

# 安装依赖
yarn --registry=https://registry.npmmirror.com

# 启动服务
yarn dev

The registry flag is the detail worth noting. The default install points at a domestic Chinese npm mirror rather than the public registry, which is a speed and reachability decision for the project's primary audience. If you are outside that network path and the mirror is slow, swapping to the public registry is the first thing to try.

There is no install step for a backend because there is no backend here. The dev server runs on port 80 according to the README, and the scripts section adds a `preview` command for serving a production build locally. Nothing in the manifest declares an engine requirement or a package manager version, so yarn versus npm versus pnpm is your choice, and the lockfile situation is not documented on this page.

The result of `yarn dev` is a running frontend pointed at whatever API base URL the environment file configures. Until you run a compatible backend alongside it, the login will succeed visually and fail on the first real request.

Eighteen built-in modules, most of them about permissions

The built-in feature list is where the framework's actual opinions show. Eighteen items, and the first six are all about who may do what.

User management configures system operators. Department management configures the organisation as a tree, with data permissions evaluated per branch. Post management configures the job each user holds. Menu management configures navigation and, importantly, operation permissions including button-level permission identifiers. Role management assigns menus to roles and sets data-scope rules per organisational unit. Dictionary management maintains the fixed lookup values the rest of the system refers to.

The rest covers operations: parameters for dynamic configuration, notice announcements, operation logs for both normal and exceptional activity, login logs including failed logins, online user monitoring, scheduled tasks with execution result logs, and a connection pool monitor that can analyse SQL to find performance bottlenecks. That last one is more useful than it sounds, because it is the screen you want when a page is slow and you need to know which query is responsible.

Four items are worth calling out as a group. Code generation emits frontend and backend code including Java, HTML, XML and SQL, with CRUD output downloadable as an archive. System interface generates API documentation from business code. Service monitoring shows CPU, memory, disk and heap. Cache monitoring queries the cache and its command statistics. And the online form builder lets you drag form elements and generate the corresponding HTML.

Put together, that is a permission model with three independent axes: menu visibility, button-level operations, and data scope by organisation. Most admin templates give you the first two. The third is what this framework has always been for.

Dependency versions, and one override that explains itself

The manifest is worth reading because it shows how closely this project tracks the ecosystem.

Vue is at 3.5.26, Vite at 6.4.1, Element Plus at 2.13.1, Pinia at 3.0.4, Vue Router at 4.6.4, axios at 1.13.2 and ECharts at 5.6.0. The build tooling is Vite 6 rather than Vite 2, which the repository topics still list, so the topics lag the code by several major versions.

The dev dependencies are lean: the Vue plugin, `sass-embedded` for styles, `vite-plugin-compression` for gzipping build output, `vite-plugin-svg-icons` for the icon sprite, and two unplugins for auto-import and a setup-extend helper. `unplugin-auto-import` in particular is why the source does not have Vue lifecycle imports written out everywhere, and it is the kind of detail that matters when you inherit the codebase and wonder where a symbol comes from.

Then there is the override block. Both `overrides` and `resolutions` pin `quill` to 2.0.2, which is the fix for a broken transitive dependency rather than a feature choice. The presence of both keys means the pin applies whether you install with npm or with yarn, which is a small piece of care that saves an afternoon for anyone who hits the wrong one first.

Smaller dependencies tell you what the screens actually need: `fuse.js` for client-side search, `clipboard` for copy buttons, `file-saver` for downloads, `js-cookie` for the token, `vuedraggable` for drag-and-drop reordering, `vue-cropper` for avatar and image cropping, and the Vue wrapper around Quill for rich text. That is the dependency list of an admin system with a form builder and a rich text editor, which matches the feature list exactly.

Where the versions, links and releases disagree

There are several small inconsistencies, and none of them are bugs you cannot work around, but all of them will cost you a minute if you do not know they are there.

The repository field in `package.json` points at the Vue 2 project on another host, not at this repository. The license badge in the README links to a LICENSE file in that same other project rather than to this repository's own. Both are leftovers from the version split, and both mean the manifest is not a reliable source of truth about where this code lives.

The version story has a gap. The README headline says v3.9.2 and the manifest agrees, and the newest GitHub release is v3.9.2. That release was published in March 2026, while the last push to the repository is from September 2026. So work has landed since the last tagged release, and if you pin to a tag you are pinning to something roughly six months behind the working tree.

Release notes themselves are a single line each, a link to the changelog page on the documentation site. That is a deliberate choice rather than an omission, and it means the release notes you want are not on GitHub. The previous two releases, 3.9.1 in December 2025 and 3.9.0 in May 2025, show the same pattern, and the gap between those two is seven months, which is the real cadence of this project.

One last thing about the ecosystem around it: the README points at hosted demo and documentation addresses and a couple of cloud discount links. The demo account is published in the README as admin with a well-known password. That is appropriate for a demo server and entirely inappropriate to reproduce in production.

Editorial conclusion

RuoYi-Vue3 is the piece of a system that most people meet only halfway. Cloned on its own it starts, serves a login page and then fails every request, because there is no backend in this repository at all. The value of the framework is not the admin screens, which are unremarkable, but the combination: a permission model with menu, button and data-scope granularity, code generation that emits both sides, and a UI form builder, all wired to a Spring Boot and Spring Security backend with JWT. If you take it on, the things that will cost you are the coupling to that backend's API shape and the three parallel frontend lines you have to choose between deliberately rather than by accident. Run the frontend against a matching backend from day one, decide between JavaScript and TypeScript early, and read the documentation site, which is where the actual upgrade notes live.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yangzongzhuan/RuoYi-Vue3 on GitHub