vue-bag-admin splits a Vue 3 admin template into a host and plugins

The main package aggregates the pieces so a business project installs one dependency

vue-bag-admin describes itself as a plugin-based, splittable Vue 3 admin solution built for business growth, and the README adds a nuance that changes how you should read it. It is not only a backend project template, it is a plugin ecosystem that is being released in pieces. The layout, permissions, routing, requests, schema UI and plugin bootstrapping are consolidated into one main package, so a business project can start lightweight and then attach independent plugins as it needs them.

The package ecosystem table makes the layering concrete. The vue-bag-admin package is the unified main package that aggregates the host, request, UI and protocol capabilities by default, and is the recommended entry point for a business project. The @bag/core package is the protocol layer defining plugin interfaces, route meta and Schema conventions. The @bag/host-vue package is the host layer handling layout, permissions, route registration and plugin bootstrapping. The @bag/request package is the request layer, unifying HTTP and WebSocket capability and including a request debounce and throttle wrapper built on Lodash. The @bag/ui package is the component layer carrying the schema-driven components such as PmProTable, PmProForm and PmSchemaForm. Then there are @bag/plugin-shop and @bag/plugin-sys-setting as the official business example plugins, and create-vue-bag-admin as the scaffolding tool.

The reason the main package exists is stated plainly in the why-choose table: a business project installs vue-bag-admin by default, which avoids being tied to the full monorepo from the start. That is the design decision, and it is the difference between a template and a framework with a package registry.

The technical stack is Vue 3.5, Vite 6, Naive UI 2.40, TailwindCSS 3.4, Pinia and Vue Router 4, managed as a pnpm workspace with turbo driving the task graph.

Scaffolding produces a minimal host, not the whole monorepo

Creating a new project takes four commands:

npx create-vue-bag-admin my-admin
cd my-admin
pnpm install
pnpm dev

The README is specific about what the scaffolding does. The scaffold currently uses templates/basic to generate a minimal host template, and by default only installs vue-bag-admin. When the project needs official business capabilities such as a shop or system settings, you then install the matching @bag/plugin-* package as needed.

That is the whole point of the split. A team that only needs login, a dashboard, a layout, a 403 page, a 404 page and request wrapping gets exactly that and nothing else, and the README lists those as the ready-made out-of-the-box capabilities. A team that later needs the shop plugin adds it, and a team that writes its own business module writes it against the plugin interface in @bag/core and ships it as its own package.

Working inside the monorepo is a different set of commands. The README gives pnpm install followed by pnpm --filter admin dev for the frontend host application, and then a separate path for the reference backend, which needs a MySQL database named vue_bag_admin prepared in advance:

cd apps/strapi
cp .env.example .env
pnpm dev

The common commands table covers the rest of the workflow. pnpm --filter @bag/docs dev starts the VitePress documentation site, pnpm dev starts everything except Strapi, pnpm dev:all starts everything, pnpm build builds all packages and apps, and pnpm check-types runs the type checks.

The requirement table is strict and worth reading twice. Node.js v24.4.1 or higher, pnpm v9 or higher, and MySQL 8.0 or higher for the Strapi 5 reference backend only. The README also explains a small detail that will otherwise confuse you: the.nvmrc and.nvmdrc files in the repository use the full version number 24.4.1, because some version managers cannot parse the 24 shorthand.

Permission handling is a closed loop from route to button

The permission model is the feature a business team will spend the most time on, and the README describes it as a closed loop supporting dynamic routing, menu permissions and button-level permissions, and working with Strapi 5 to complete the full-stack permission flow.

Three levels of permission is the shape of most Chinese admin systems, and this one covers all three. Route level decides what a user can reach, menu level decides what they see in the sidebar, and button level decides what controls render inside a page. The protocol layer in @bag/core is where route meta is defined, which means the permission contract is a shared convention rather than something each host application reinvents, and that is what makes a plugin portable between hosts.

The host layer in @bag/host-vue is responsible for layout, permissions, route registration and plugin bootstrapping. Separating that from the protocol layer is the interesting architectural choice. The protocol layer defines the shapes, and the host layer implements the runtime, so a plugin written against @bag/core can be dropped into any host built on @bag/host-vue, which is exactly the property that makes a plugin ecosystem worth having.

The Strapi 5 reference backend under apps/strapi exists to demonstrate the other half of that loop, where permission data comes from a server rather than being hardcoded in the frontend. It is a reference implementation rather than a requirement, and the requirement table says MySQL is needed only for it.

The README also points to a plugin development guide at apps/docs/guide/plugins/create-plugin.md and a host layer description at packages/host-vue/README.md, which are the two documents to read before writing a plugin.

Schema-driven UI is what makes the table and form packages reusable

The @bag/ui package is described as carrying Schema driven components, and the three names it lists are PmProTable, PmProForm and PmSchemaForm. A fourth package, @bag/core, is where the Schema protocol itself is defined.

That separation is the design. The protocol layer defines the Schema conventions, and the component layer renders them. So a table or a form is described by data rather than by template code, and the same Schema can drive a list, an edit form and a detail view without three hand-written templates.

This is the mechanism behind the plugin model. If a business plugin could only ship Vue components, each host would have to trust the plugin's markup and its styles, and the host's conventions could not be enforced. If the plugin ships Schemas plus behaviour, the host renders them with its own components, and the plugin inherits the host's look and its permission model for free.

The request layer fits the same pattern. @bag/request unifies HTTP and WebSocket capability and ships a debounce and throttle wrapper built on Lodash, which is the sort of detail that a business plugin would otherwise reimplement per request.

The version state of the UI stack is what you would expect from a project that rebuilds against current versions: Vue 3.5, Vite 6, Naive UI 2.40 and TailwindCSS 3.4, with the topics on the repository naming naive-ui, pinia, vite5, vue-router4 and vue3.

The visual result is not what you would get from a component gallery, though. The UI design was modelled around a familiar layout for administrators, which is the point of an admin template, and the online demo linked from the README is the fastest way to judge it.

Turbo drives the build, and only the main package has a release script

The root package.json shows how the monorepo is wired and, more interestingly, which part of it is actually published.

The root package is named turbo-bag-admin and is private. The build and dev tasks are turbo tasks, with build running turbo run build and dev running turbo run dev with a filter that excludes strapi, which is how pnpm dev starts everything except the reference backend. There is a turbo.json at the root and a pnpm-workspace.yaml, plus a .npmrc and a pnpm-lock.yaml. Formatting is prettier over ts, tsx and md, and commit messages go through commitlint with the conventional config. Husky is the pre-commit hook, with a .husky/ directory and a prepare script that installs it. There is also a preinstall script that runs npx only-allow pnpm, so the workspace refuses npm installs outright.

Then there is the release machinery, and it is telling that every release script is scoped to one package. There are separate version:patch, version:minor and version:major scripts for vue-bag-admin, each calling npm version with a prefix of ./packages/vue-bag-admin and --no-git-tag-version, and separate release scripts that build that package with turbo and then npm publish it with --access public. There is a release:dry-run script that does the same with --dry-run, and a pack:vue-bag-admin script that builds and packs the tarball locally.

The main package has a full release path. The other packages in the ecosystem do not have one in the root manifest, which matches the README's description of an ecosystem being released in pieces. For anyone depending on @bag/core or @bag/ui directly, the practical consequence is that they are consumed from the workspace or from a source install rather than from a versioned registry release, and the main package is the supported surface.

The licence is worth a note. The README carries an MIT badge, while the repository's own metadata records the licence as unknown with a pointer to a licence field. The MIT claim in the project badge is the statement to rely on.

Editorial conclusion

Adopt vue-bag-admin if you are building an internal admin product and want layout, permissions, routing, request handling and schema-driven forms in one place while keeping business modules in separately installable plugins. Do not adopt it if you want a single-file template you can read in an afternoon, because the answer here is a monorepo with a protocol layer and a host layer to learn. Before you start, confirm your environment runs Node v24.4.1 or newer and pnpm v9 or newer, note that the repository ships an MIT badge while the package metadata records no licence, and expect to add a MySQL 8.0 database only if you want to run the Strapi 5 reference backend.

Frequently asked questions

Official sources

1. hangjob/vue-bag-admin on GitHub
2. Issues
3. Project website
4. README
5. Releases