fast-vue3: A Vue 3 Monorepo for Admin and Public Sites

A Monorepo for Seven Vue UI Ecosystems

fast-vue3 addresses a specific starting-point problem: a team that wants to build Vue 3 applications but does not want to recreate the same application structure separately for Ant Design Vue, Arco Design, Element Plus, iDux, Naive UI, PrimeVue, and TDesign Vue Next. The repository describes 14 framework applications. For each of the seven UI ecosystems, there is an admin app and a site app.

The administrative applications cover dashboards, users, roles, menus, content, logs, configuration, and monitoring. The public applications cover home, product, pricing, FAQ, blog, authentication, and contact pages. That breadth makes the project closer to an application platform or starter collection than a single component template. It is most relevant to teams that need to compare UI ecosystems, prototype several frontends, or keep public and administrative surfaces within one repository.

The package description calls the project a Vue 3 monorepo engineering platform. The repository layout supports that description: application code lives under `apps/`, reusable API, request, state, preference, style, type, utility, locale, and constant modules live under `packages/`, and shared tooling lives under `internal/` and `scripts/`. The scope is useful for standardized work, but it also introduces the need to understand workspace commands and package boundaries before changing a feature.

Shared API Types and Response Handling

The main architectural decision is the shared API layer. The README names `packages/effects/api/src/types.ts` as the frontend source of truth. According to the README, all 14 applications consume the same typed API contract, while the bundled Nitro Mock and the separate Spring Boot server return the same response envelope:

{ "code": 0, "message": "success", "data": {} }

Paginated responses use an object containing `items`, `page`, `pageSize`, and `total`. The shared request package is described as an Axios client with response-envelope handling, and shared Pinia stores and preference modules are available to the applications. This keeps transport and domain concerns out of each individual UI implementation.

The contract is coupled across several layers. When adding an endpoint, the project documentation says to update the shared types or client, the Nitro route, the Spring controller and service, and contract or integration tests together. That is a clear maintenance rule, but it also makes a simple endpoint addition a wider change than editing one Vue component. The repository favors consistency across backends and UI variants, at the cost of requiring coordinated edits when the API changes.

Nitro Mock and Spring Boot Development Modes

The default development path uses a bundled Nitro API mock. This is convenient for front-end work because it does not require a Java installation or the sibling server repository. The shared Vite configuration proxies frontend requests under `/api/v1` to either the mock or the Spring Boot service, depending on the selected backend mode.

The mock is a separate application under `apps/backend-mock`, and the documentation says `pnpm dev:mock` starts the selected frontend with its own Nitro Mock. The standalone mock can run on port 5320 with `pnpm dev:mock:api`. The README explicitly states that this mock does not call the Spring Boot service. The two modes therefore test different integration conditions. A frontend can appear complete against the mock while server-specific behavior still needs checking against Spring Boot.

For the server path, `pnpm dev:server:api` uses Docker Compose from the sibling `fast-vue3-server` repository. The README also documents a local JDK 21 path using `docker compose up -d` and `./mvnw spring-boot:run` from that server directory. The documented health endpoint is `http://localhost:8080/actuator/health`, and Swagger is available at `http://localhost:8080/swagger-ui.html`. The backend host can be changed with `VITE_FAST_VUE3_SERVER_URL`, while `VITE_DEV_BACKEND=server` selects server mode.

Installing pnpm and Starting the First Application

The README lists Node.js `>= 20.12.0`, pnpm `>= 9.5.0`, and Git `>= 2.30` as requirements. After cloning the repository, install the workspace dependencies with the documented command:

pnpm install

Start the default interactive development flow with:

pnpm dev

This selects an application interactively and uses Nitro Mock by default. The reader should see the application selection interface, then the chosen front end and its mock service start according to the repository configuration. To start one named application directly, use one of the documented commands, for example:

pnpm dev:web-antd

For a public application, the equivalent command is:

pnpm dev:site-antd

The mock login credentials documented for development are `admin / 123456`. These are mock credentials, not production credentials. The Spring Boot server path uses the documented development credentials `admin / admin123`. The distinction matters because switching backends changes both the target service and the credential set.

Public Authentication and Payment Boundaries

The public-site templates define a clear authentication boundary. Public pages and content endpoints do not require login. User interactions such as posting a blog comment or starting checkout require a Bearer access token. The README lists public routes such as `/public/home`, `/product`, `/features`, `/about`, `/docs`, `/faq`, and `/pricing`, along with public blog and contact endpoints.

The pricing page includes a checkout dialog with Alipay, WeChat Pay, and card channel selection. It creates a pending payment order, and the login flow returns users to the pricing or blog page where they began. The bundled checkout is explicitly a safe demo adapter. It persists an order and returns `checkoutUrl`, but it does not charge real money. A production deployment must exchange that URL through a payment-provider integration and implement signed callback verification.

This is a useful example of the template's boundary between demonstration and production behavior. It also rules out treating the demo checkout as a complete payment system. Teams needing real payment collection still have to supply provider credentials, provider-side checkout handling, callback verification, and the relevant operational controls.

Scaffolding, Quality Checks, and Upgrade Cost

The project includes commands for standard checks and single-application builds. The quality commands are:

pnpm lint
pnpm format
pnpm typecheck
pnpm test
pnpm build

An individual admin or site application can be built with commands such as `pnpm build:web-antd` and `pnpm build:site-antd`. The workspace uses Turbo for the top-level build, with `NODE_OPTIONS=--max-old-space-size=8192` configured in the `build` script. This suggests that the full multi-application build can require substantial Node memory, although the README does not document a measured memory requirement.

For new applications, the documentation provides `pnpm create-app`. The CLI creates an admin or site app for one of the seven supported UI ecosystems and adds canonical `dev:<app-name>` and `build:<app-name>` scripts. That reduces the need to hand-edit workspace scripts, but it does not remove the need to decide which UI ecosystem the application should use.

The repository is MIT licensed according to the README. No GitHub releases are published, and the last push was on 2026-09-27. As a result, users should treat the repository source and `pnpm-lockfile.yaml` as the practical upgrade artifacts. The README does not document a migration or rollback procedure for older versions.

Choosing fast-vue3 Instead of a Minimal Vue Starter

A realistic alternative is to start with a minimal Vue 3 and Vite TypeScript application, select one UI component library, and add only the dependencies needed for that application. That approach produces a smaller repository and fewer framework variants, but the team must define its own API typing, request envelope handling, state organization, layout preferences, backend proxying, mock service, and application scaffolding.

fast-vue3 takes the opposite approach. It supplies several admin and site applications, shared packages, two documented backend paths, and a consistent `/api/v1` contract. The trade-off is repository size and coordination. A change to a shared API type can affect multiple UI ecosystems, and a full build covers more than one application. A team that only needs one small public page may find that the monorepo provides more structure than it needs.

The choice therefore depends on the desired starting point. Choose the smaller single-app route when scope is narrow and internal conventions are already settled. Choose fast-vue3 when shared contracts, multiple UI options, and a reusable admin or site structure are part of the initial requirement.

Editorial conclusion

Adopt fast-vue3 when a team needs several Vue 3 frontends sharing typed APIs, Pinia stores, preferences, and backend modes. Do not choose it as a minimal single-page starter, and verify the selected UI ecosystem, server repository, payment integration, and deployment requirements before committing. The last push was on 2026-09-27, while the repository has no GitHub releases, so the practical upgrade path is the source tree and lockfile rather than a documented release stream.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. tobe-fe-dalao/fast-vue3 on GitHub