Fes.js for Vue 3 Admin Applications

Fes.js Targets Repeated Admin Application Work

Fes.js addresses a specific class of frontend work: internal applications and management consoles that repeatedly need the same foundations. The repository lists workbenches, CRUD interfaces, permissions, charts, and related business patterns as common application types. Before writing application features, teams often have to prepare a development environment, define code conventions, wrap API requests, configure routes, implement layouts and navigation, and add login and permission management. Repeating that work separately in each project can consume time and produce inconsistent stacks and project structures.

The framework is based on Vue.js 3.0 and uses TypeScript as its primary language. Its design combines conventions, configuration, and components. The intended user is a frontend developer or application team that wants to concentrate on page content while using a common set of application services. It is not limited to one particular visual design. The README describes layout, access, internationalization, state management, API requests, data dictionaries, SVG icons, testing, Sass, Monaco Editor, Windi CSS, watermarks, and micro-frontends as plugin-provided capabilities.

That scope makes Fes.js closer to an application framework than a single UI component library. The choice is useful when the same platform requirements recur across several projects. It also creates a framework dependency, so a team should account for plugin compatibility and upgrade decisions when comparing it with a plain Vue setup.

Routing and Plugins Form the Fes.js Application Core

The documented foundation is routing. Fes.js supports both configuration-based routes and convention-based routes, with routing treated as a central part of application organization. The plugin system covers the lifecycle from compilation and construction through application runtime. Plugins can manage both compile-time and runtime behavior, which allows capabilities to be added without placing every concern in the page components.

For example, the access plugin provides page-level resource permission control, while the layout plugin provides a configured layout containing navigation and a sidebar. The request plugin is based on Axios and includes duplicate-request prevention, request throttling, and error handling. The state options include plugins built around Vuex and Pinia. Other plugins add locale support through Vue I18n, Jest-based tests, automatic registration of SVG files as components, enum storage and helper functions, and a model-based data management option.

The README also describes support for webpack 5 and Vite. A micro-frontend plugin is based on qiankun, and the Sass plugin handles Sass styles. The framework therefore offers several extension points for build and runtime concerns. The repository layout contains a package workspace under `packages/` and scripts for development, builds, tests, linting, documentation, releases, and cleaning. That structure is consistent with a monorepo containing framework packages and related tooling, although the README does not document every package or plugin configuration key.

Creating a First Fes.js Application

The README gives two documented setup paths. The pnpm path creates a template, installs dependencies, and starts the development server. Replace `myapp` with the directory name for the application.

# Create the template
pnpm create @fesjs/fes-app myapp

After the command completes, the application should be created in the `myapp` directory. The README then documents installing its dependencies and running the development script.

# Install dependencies
pnpm i

# Run
pnpm dev

The npm path uses the corresponding npm command for template creation, followed by npm dependency installation and the package development script.

# Create the template
npx @fesjs/create-fes-app myapp

# Install dependencies
npm install

# Run
npm run dev

These commands start the generated application in development mode. The README does not specify a port, output URL, environment variable, or exact files produced by the template, so those details should be taken from the generated application rather than inferred from the framework repository. The root `package.json` identifies `[email protected]` as its package manager, while the README presents both pnpm and npm workflows.

Choosing Plugins for Application Services

Fes.js separates common application services into optional plugins rather than requiring every project to implement the same infrastructure from the beginning. A project that needs a sidebar and navigation can use the layout plugin. A project that needs page permissions can add the access plugin. API handling belongs to the request plugin, which is based on Axios and adds duplicate-request prevention, throttling, and error handling. These are separate concerns with different configuration surfaces.

State management is a choice rather than a single imposed answer. The repository lists both `@fesjs/plugin-vuex` and `@fesjs/plugin-pinia`. The former is based on Vuex, while the latter provides Pinia state handling. Similarly, internationalization is provided through a plugin based on Vue I18n, and testing through a plugin based on Jest. This permits an application to retain familiar Vue ecosystem choices while using the same application-level conventions.

The plugin model also reaches areas that normally require direct integration work. `@fesjs/plugin-icon` automatically registers SVG files as components. `@fesjs/plugin-monaco-editor` integrates the VS Code editor. `@fesjs/plugin-qiankun` provides micro-frontend capability. `@fesjs/plugin-watermark` adds watermarking, and `@fesjs/plugin-windicss` provides atomic CSS support. The README does not document whether every plugin is compatible with every Fes.js release, so version alignment should be checked before selecting several of them.

Where Fes.js Is the Wrong Level of Tooling

The main limitation is scope. Fes.js assumes that a project needs an application framework and several shared services. A small Vue 3 site with one page, a small component set, and no admin layout, access model, or request abstraction may carry unnecessary framework and plugin decisions. The framework does not remove the need to design routing, permissions, authentication, data handling, or deployment. It organizes those concerns and supplies plugin implementations.

Convention-based routing also creates a tradeoff. It can reduce setup work and make project structure more predictable, but it may be less transparent than an explicitly assembled router when a project has unusual route behavior. The README confirms support for configuration-based routes as well, which provides an alternative when conventions do not fit. It does not, however, document route precedence, conflict handling, or migration behavior in enough detail to make those decisions without consulting the project documentation.

The framework's broad plugin set can also increase upgrade work. A repository release introduces changes across a package ecosystem rather than a single library file. The release history shows v4 beta releases after a v3 patch release, and the root `package.json` version is `4.0.2`. That version information indicates a transition in the documented release history. Teams should review `CHANGELOG.md`, package compatibility, and migration notes before standardizing on a major version.

Fes.js Compared With a Direct Vue Application

The closest practical alternative is a direct Vue 3 application assembled from the Vue ecosystem. That approach can use Vue's own router, Axios, Pinia or Vuex, Vue I18n, and a test runner directly. Its difference is architectural: the team chooses and connects each package, while Fes.js supplies a lifecycle plugin system and conventions intended to coordinate application development.

For one small application, direct Vue may be easier to understand because there are fewer framework layers. For several internal applications, Fes.js can make layouts, routing, access, requests, and testing available through a common project model. The repository's `package.json` includes `dev`, `build`, `test`, `lint`, and documentation commands, indicating a framework-sized development workflow rather than only a UI package.

A second alternative is to use another Vue application framework that provides comparable routing and build conventions. The README says the plugin mechanism was inspired by Umi, but it does not provide a feature-by-feature comparison or claim feature parity. The decision therefore depends on the exact plugins, routing rules, build integration, and migration requirements of the target application.

Maintenance, Licensing, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-09-14. That is the maintenance fact stated by the repository record. The release history lists `v4.0.0-beta.1` on 2025-09-22, `v4.0.0-beta.0` on 2025-09-16, and `v3.4.12` on 2025-06-24. These entries show that the project has published both v4 beta and v3 patch releases. They do not establish compatibility between those lines.

The repository declares the MIT license, and the README links to the MIT open-source license information. That is the licensing fact relevant to an initial review. This review does not interpret the license or provide legal advice. Teams should still check the license files for applications, plugins, and dependencies they distribute.

The workspace is managed with `[email protected]` in the root `package.json`. Scripts include `bootstrap`, `dev`, `build`, `release`, `clean`, `docs:dev`, `docs:build`, `test`, `lint`, `changelog`, and `hooks:sync`. Upgrade cost depends on how many Fes.js plugins an application adopts and whether it follows the v3 or v4 line. The README does not provide a complete upgrade guide. The project-specific files `CHANGELOG.md` and `docs/` are the relevant starting points for reviewing changes between releases.

Editorial conclusion

Fes.js fits teams that repeatedly build Vue 3 admin applications and want shared application conventions rather than a collection of isolated utilities. It is less suitable for a small application that needs only Vue and a client-side router. Before adoption, verify that current plugin versions match the application needs, especially for state management, authentication, build tooling, and micro-frontends.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. WeBankFinTech/fes.js on GitHub