# SnowAdmin: A Vue 3 and Vite 7 Admin Template With Button Level Permissions > SnowAdmin is an open source admin template built on Vue 3, TypeScript, Vite 7, Pinia and Arco Design, with an RBAC model that covers routes, roles and individual buttons, several layout styles, dark mode, internationalisation and cached nested tabs. It runs on pnpm and ships a full branch and a minimal one. **imwangfan/SnowAdmin** — SnowAdmin 一款基于 Vue3、TypeScript、Vite7、Pinia、Arco.Design 开源的后台管理框架，符合直觉的使用模式，使用目前最新技术栈开发。 - Repository: https://github.com/imwangfan/SnowAdmin - Website: http://124.223.224.174/#/login - Stars: 1,061 · Forks: 171 - Language: Vue - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/imwangfan-snowadmin ## A Template Meant to Be Extended, Not Just Copied SnowAdmin describes itself as a clean, elegant and capable admin template built on the current front end stack, namely Vue 3, Vite 7, TypeScript and Pinia, with built-in theme configuration and components, strict code conventions and an automated file based routing system. The claim is that it provides a one-stop admin solution with no extra configuration, ready to use, and that it also works as a best practice example for learning the newer tooling. The repository is hosted in two places, GitHub and Gitee, and the README is explicit that the maintenance happens on GitHub and that issues and pull requests should go there. There are two branches, and the difference is a real one: main is the full version and main-thin is the minimal version. A team that wants the layout, tabs and theming machinery should take main, and a team that wants a bare skeleton should take main-thin. The package metadata says the package is named snow-admin, is private, at version 1.0.0, and is an ES module project, and it declares the MIT licence. There is also a demo instance and a development guide, both served from a single address, which is a useful way to see the finished interface before cloning anything. ## RBAC That Reaches Down to the Button The permission model is the part of an admin template that either works or does not, and SnowAdmin states that it includes an RBAC role and permission model covering route, role and button level access control. Three levels is the meaningful claim. Route level is the common one, where a menu entry is hidden or a path is blocked. Button level is the part most templates skip, and it is what stops a user who can see a page from also pressing the delete button on it. The README pairs this with the use of VueRouter for dynamic route permission interception and lazy loading, and with the custom directives in the source tree, which include a permission directive alongside the debounce and throttle ones. So the enforcement happens in more than one place, which is what you want, since a single guard is easy to bypass with a direct URL. The directory listing makes the shape of this visible. There is a router/ directory for route management, a store/ directory for the Pinia stores, a directives/ directory with the global custom directives, a permission/ view demonstrating the model, and a config/ directory for global configuration items. The feature list also mentions page level button permission control alongside the router interception in the same bullet. The demo includes a multilevel menu view as well, so the route tree is a real nested case rather than a flat one. ## Layouts, Tabs, Theme Switching and Dark Mode The presentation layer is unusually rich for a template, and the feature list enumerates it: Arco Design component size switching, multiple theme layouts, dark mode and internationalisation, with the layout module providing the components. The layout directory is where the structure lives. It has a components/ subdirectory holding the Aside, Header, Footer, Menu and Tabs components, and a set of layout type directories named defaults, head and mixing. That is the mechanism behind the layout screenshots in the README, which show a horizontal layout and a mixed layout, so the shell is not hard coded to one arrangement but assembled from a layout type. The Tabs component is what makes this feel like a desktop application rather than a website, and the caching behaviour is the part to notice. The README says KeepAlive is used to cache pages, with support for multi-level nested route caching, so a tab that holds a nested route keeps the nested state alive when you switch away and come back. The dark mode is a first class citizen rather than a class on the body element, with three separate dark mode screenshots in the preview, and the theme configuration screen is exposed as a page, which means the theme is something a user can change at runtime rather than a build time value. ## Pinia With Persistence Instead of Vuex The state management choice is stated as a migration rather than an addition: Pinia is used in place of Vuex, described as lighter, simpler and easier to use, with the Pinia persistence plugin integrated. The persistence plugin is what makes it a template rather than a demo. A store that survives a page reload is the difference between an admin panel that remembers your settings and one that forgets them on every navigation, and pinia-plugin-persistedstate is in the dependency list for exactly that reason. The rest of the dependency list shows the range of the template. Arco Design for the component library, axios for the API layer, echarts 6 for the system monitoring view, wangeditor for the rich text editor, CodeMirror 6 with the Vue, JSON and JavaScript language modes, @vue-flow/core for a node graph editor, @vueuse/core for composables, driver.js for the guided tour, nprogress for the loading bar, jsbarcode and qrcode for codes, fingerprintjs for device identification, pinyin-pro for Chinese pinyin sorting, and print-js for printing. The src/ directory also has a mock/ directory for local data mocking, which is the feature that lets a frontend developer work on pages before the backend endpoints exist. ## Getting It Running With git, Node and pnpm The environment requirements are stated as important. You need git for cloning and version management, NodeJS 18.12.0 or newer with 20.12.0 or later recommended, and pnpm 8.7.0 or newer with the latest version recommended. Cloning is one command, and the Gitee mirror has its own: ```bash # 克隆代码 git clone https://github.com/imwangfan/SnowAdmin.git ``` Then the dependencies, with pnpm rather than npm: ```bash pnpm install ``` The choice of package manager is enforced rather than suggested. The package.json has a preinstall script that runs npx only-allow pnpm, so an npm install fails with an explanatory error, and the prepare script runs husky to install the git hooks. In an editor, the recommendation is the Vue - Official extension with Vetur disabled, since having both installed confuses the tooling. The build scripts are the standard Vite set with type checking folded in: ```json "dev": "vite", "build:dev": "vue-tsc && vite build --mode development", "build:prod": "vue-tsc && vite build --mode production", "build:test": "vue-tsc && vite build --mode test", "preview": "vite preview" ``` Running vue-tsc before each build is what makes the TypeScript part of the stack real rather than decorative, since a type error fails the build. ## The Directory Tree as Documentation The README prints the whole source tree, and it is the best documentation in the repository because it shows where everything lives and, more usefully, what the conventions are. Under src/ there is api/ with a modules/ subdirectory for the API interface management, assets/ with fonts, img, logo and svgs, a global components/ directory holding shared components such as the code view, a QR code component and an SVG icon component, config/ for global configuration, directives/ for the global custom directives, globals/ for global functions, hooks/ for common composable wrappers, lang/ for the internationalisation files, layout/ for the shell, mock/ for local data, router/ for routing, store/ for the Pinia stores, style/ for global styles, typings/ for global TypeScript declarations, utils/ for the utility library, and views/ for the pages. The views/ list is the clearest description of what the template covers: error pages for 401, 404 and 500, a file management page, a form page, a functions page, a home page, an internationalisation demo, a link demo, the login page, a system monitoring page, a multilevel menu demo, a permission demo, a personal centre, a system management section, a table page and a thin preview page. The style/ directory has the same structure, with media/ for responsive styles, model/ for animations, scrollbars and global styles, and var/ for the theme variables, which is where the dark mode palette is defined. ## Quality Gates, Browser Support and Where It Ends The formatting and linting story is thorough enough to copy into your own project. Prettier is used for consistent formatting, with ESLint and Stylelint for the checks, and the commit pipeline uses husky, lint-staged and commitlint so that the commit message convention is enforced by a hook rather than by review. The configuration files for all of that live at the root, with prettier.config.ts, stylelint.config.ts, eslint.config.ts, lint-staged.config.ts, commitlint.config.ts, an .eslintrc-auto-import.json for the auto import setup and a .prettierignore. The .husky/ directory holds the hook definitions, and the .github/ directory holds the issue templates. The repository also carries .editorconfig, a .gitignore and separate .env, .env.development, .env.production and .env.test files, so environment configuration is separated by mode. Browser support is stated plainly. For local development the latest Chrome is recommended, and for production modern browsers are supported with IE no longer supported, with a pointer to the ES module compatibility tables for the details. The limits of the template are the usual ones, and they are worth stating before you adopt it. It is a front end template, so the API layer, the mock data and the login flow all have to be replaced with your own backend contract, and the RBAC model assumes a backend that returns menus and roles in the shape the template expects. The MIT licence lets you change any of that, and the preinstall hook and the file naming conventions are things you inherit along with the code. ## Conclusion SnowAdmin fits a team that needs an internal admin panel quickly and would rather start from a template with routing, permissions, layouts and internationalisation already wired than from a bare Vite project, and it does not fit a team whose backend contract or design system differs enough that the template's conventions become work to undo. Before adopting it, read the directory tree rather than only the screenshots, since the permission model is spread across router, store and directives, and pick the branch deliberately, since main is the full version and main-thin is the minimal one. The project is MIT licensed, the package version is 1.0.0, the last push was on 2026-10-15, and it publishes no GitHub releases. ## FAQ ### How do I install and run SnowAdmin? Clone the repository with `git clone https://github.com/imwangfan/SnowAdmin.git`, install the dependencies with `pnpm install`, and start the dev server with the dev script, which runs vite. The environment needs Node 18.12.0 or newer with 20.12.0 recommended, and pnpm 8.7.0 or newer, and a preinstall script blocks npm with npx only-allow pnpm. ### What permission model does SnowAdmin implement? An RBAC role and permission model covering route, role and button level access control, with VueRouter used for dynamic route permission interception and lazy loading, plus a global permission directive alongside the debounce and throttle directives. The repository includes a permission demo page and a multilevel menu demo. ### What is the difference between the main and main-thin branches? The README states that main is the full version and main-thin is the minimal version. Maintenance happens on GitHub, so issues and pull requests should be raised there rather than on the Gitee mirror. ### Which state management library does SnowAdmin use? Pinia, used in place of Vuex and described as lighter and simpler, with the Pinia persistence plugin integrated so that store state survives a page reload. The store/ directory under src/ holds the Pinia stores. ### Does SnowAdmin support dark mode and internationalisation? Yes. The feature list includes Arco Design component size switching, multiple theme layouts, dark mode and i18n, and the README shows a theme configuration page as one of the built-in components, with the theme variables under src/style/var/ and the language files under src/lang/. ## Sources - [imwangfan/SnowAdmin on GitHub](https://github.com/imwangfan/SnowAdmin) - [Issues](https://github.com/imwangfan/SnowAdmin/issues) - [License: MIT](https://github.com/imwangfan/SnowAdmin/blob/main/LICENSE) - [Project website](http://124.223.224.174/#/login) - [README](https://github.com/imwangfan/SnowAdmin/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/imwangfan-snowadmin