# Pro React Admin: a React 19 admin workspace with its own component package

> Pro React Admin is a TypeScript monorepo that ships three things at once, a demo admin application, a simplified enterprise entry with users, roles and audit pages, and a standalone component library called @w.ui/wui-react, plus multi-project builds and a Module Federation example. The tooling is thorough, and the Node version required for local work does not match the version baked into the Dockerfile.

**wkylin/pro-react-admin** — 一款基于 React v19 的高性能、企业级中后台前端解决方案...

- Repository: https://github.com/wkylin/pro-react-admin
- Website: https://pro-react-admin.vercel.app/
- Stars: 947 · Forks: 222
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/wkylin-pro-react-admin

## Three deliverables in one workspace, not one admin template

Pro React Admin describes itself as an enterprise admin application and component workspace built on React 19, Ant Design 6, React Router 7, Zustand 5, Webpack 5 and TypeScript 6. The README then lists what the workspace actually produces, and this is the part worth reading twice, because it is more than a starter template.

There is the full demo application, which is the demo you can browse at pro-react-admin.vercel.app. There is a simplified enterprise entry, which is a smaller admin surface built around a workbench, user management, role management and audit management. There are multi-project builds, so one dependency set can produce several branded applications from a shared core. There is a Module Federation host and remote example. And there is the standalone component package `@w.ui/wui-react`, which is published separately to npm and is designed to be consumed on its own.

That last point is what separates this from the usual admin template. The value of the repository is not the screens, it is the extracted UI package plus the build machinery around it. A company that wants a design system and an admin skeleton from the same source tree can take the package and ignore the applications, or take the applications and ignore the package.

The package.json identifies the project as `pro-react-admin` at version 5.1.0, marked private, and its keyword list includes Ant Design, TypeScript, React Router, Webpack, ESLint and the Bit tooling names. The Storybook is published separately, and a portal page on GitHub Pages links the various deployed applications. The repository topic tags still list antd5 and reactrouter6, which is a reminder that the tags lag the versions the README describes.

## Node 24, pnpm 11.5.2, and a password that the browser makes up

The quick start is unusually precise about its environment: Node.js 24.15.0 or newer but below 25, and pnpm 11.5.2.

The clone and run sequence is:

```bash
git clone https://github.com/wkylin/pro-react-admin.git
cd pro-react-admin
pnpm install --frozen-lockfile
pnpm start
```

The frozen lockfile flag matters in a workspace of this size, since it keeps the install reproducible against the committed lockfile rather than resolving newer versions of anything.

`pnpm start` launches the full demo application together with a local API. The API starts at port 5200 and increments from there if that port is taken, and the front end proxy is kept in step with it, so the exact ports come from the terminal output rather than from documentation. Development telemetry is held in memory, so no MongoDB is required for local work, which is a meaningful simplification for a first run.

The login flow deserves a note, because it is unusual. You open the signin page at `http://localhost:8080/#/signin`, click the `admin@test.com` entry, and the demo password for that account is generated in the current browser and filled in automatically. There is no fixed shared password. You then sign in and complete a slider verification step. In other words, the demo credentials are per browser session, and there is no single password to paste into a README. Anyone expecting a conventional demo account will find the mechanism confusing on the first attempt.

The local environment file follows the same pattern. A template is provided as `.env.development.local.example`, and the first run creates the real file from it with a short node command that copies the template only if the file does not already exist. The actual file is git ignored, and the default demo configuration contains no password at all.

## Mock mode and the enterprise entry behind the login page

The default application runs with the mock flag set in the template, while the enterprise entry has to be started with mock mode turned on explicitly in the command:

```bash
pnpm exec cross-env REACT_APP_USE_MOCK=true pnpm run start:enterprise
```

The reason for the asymmetry is visible in the scenario table: the default application and the API are started by `pnpm start`, while the enterprise demo needs the flag passed in, because the enterprise entry is a separate target rather than a route inside the default app.

What the enterprise entry contains is a working admin surface: a workbench, user management, role management and audit management, reachable at `/#/administration/users`, `/#/administration/roles` and `/#/administration/audit` after signing in.

Several demo accounts exist so that permissions can be compared: `admin@test.com`, `manager@test.com`, `business@test.com` and `user@test.com`. You sign out and sign in as another one to see the difference in what each role can reach. Clicking an account on the signin page fills in the password that the browser generated for it.

Two documented behaviours are worth knowing before you build a demo on top of this. The demo data resets on refresh, so anything you change in the UI is temporary. And editing a demo role does not change the permissions of the test accounts, and does not create a new user that can sign in. Those two rules mean the demo is safe to poke at but is not a seed mechanism for a real tenant, which is exactly what the separate full mode is for: `pnpm run start:enterprise:full` runs the real tenant login path, using the tenant ID, email and password set during initialisation.

## One dependency set, several branded applications

The multi-project feature is the part of the workspace aimed at a company that runs more than one branded admin. The commands are driven through a small script rather than a hand-written config per app.

There are helper commands to list the configured projects and to diagnose the environment:

```bash
pnpm run project:list
pnpm run project:doctor
```

Each project then runs on its own port, so two applications can be open at the same time:

```bash
pnpm exec cross-env PORT=8091 pnpm run project:dev projectA
```

The example set contains `projectA`, which reuses the demo routes and needs a demo login, and `projectB`, which is a public example that does not require signing in. The build step writes a separate output directory per project, `dist-projectA` and `dist-projectB`, and the `PROJECT` variable selects which one the static preview serves on port 5000.

Creating a project has a dry run, which is a sensible touch given how many files a new app directory pulls in:

```bash
pnpm run project:create customer --dry-run
```

The idea is that branding, routes and locale content differ per project while the components, the state layer and the build configuration are shared from one install. The cost is complexity: a monorepo with a project CLI, a doctor command, per-project output directories and an environment variable that selects which build is served. A team with one internal admin and no plans for more brands is carrying that weight for nothing.

## Module Federation with a shell and two remotes

The microfrontend example is a working Module Federation setup with three processes. The two remotes come up first:

```bash
pnpm run start:mf:projectA
```

```bash
pnpm run start:mf:projectB
```

and the shell last:

```bash
pnpm run start:mf:shell
```

The shell listens on 8080 and the remotes on 8081 and 8082, so all three ports have to be free before you start. Once the builds finish you open `http://localhost:8080/#/portal` and move between the public remote communication examples at `/#/projectA` and `/#/projectB`. The README is clear that these three commands start the front ends only, with no API behind them, and that the examples need no sign-in.

For a combined build there is a separate path that produces a `dist-vercel` directory and rebuilds the standalone output for the shell and both remotes, along with an artefact check step and a local static preview:

```bash
pnpm run build:mf:vercel
pnpm run check:mfe-artifacts
pnpm exec serve -s dist-vercel -l 5080
```

The value of including this in the same repository is that the federation setup is exercised against the same components and the same routing conventions as the rest of the workspace, rather than in a separate demo that drifts. The cost is that three dev servers, three build targets and an artefact validation step sit in the same tree as the single application workflow, so a newcomer has to learn which of the many commands belongs to the task at hand.

## Publishing @w.ui/wui-react, and the checks that run before it

The component library is the part meant to leave the repository, and the release path for it is spelled out in detail, down to the tarball file name and the registry flags.

The local build of the library is short:

```bash
pnpm run build:lib
```

which produces ESM, CJS, CSS and type declarations in `packages/wui-react/dist`. The fuller preparation step adds the package contract checks, a consumption smoke test and a size check:

```bash
pnpm run prepare:lib:release
npm pack ./packages/wui-react --dry-run --ignore-scripts
```

Neither command publishes anything. The npm publishing sequence for the 5.1.0 component package is longer and deliberately ordered: check the release, prepare the library, log in, confirm the identity, create the artefacts directory, pack with a fixed destination, publish that exact tarball with the `--ignore-scripts` flag, and finally query the registry for the published version.

The `--ignore-scripts` flag is there for a reason spelled out in the README: it is only used to upload a fixed artefact that has already been fully verified, so no lifecycle script runs at publish time. A published version cannot be overwritten, so an update means bumping the package version and publishing the correspondingly named tarball. If npm asks for two factor authentication after you have logged in, the README points at `npm profile enable-2fa auth-and-writes` and the same tarball can then be retried.

The quality gates around this are extensive. The `ci:quality` script chains lint, alias checks, import boundary checks, a route contract check, a documentation check, an i18n check, four separate typecheck passes covering boundaries, the API and the library, and three test runs covering the app, the tooling and the API. There is also husky for commit hooks, commitlint configuration, cspell for spelling, stylelint, eslint in flat config form, jest for unit tests, and a Storybook with 157 entries that can be previewed from the current source without building the library first, with a story validation script run against the built output.

## The Docker path does not match the documented Node requirement

Here is the sharpest inconsistency in the repository, and it is worth catching before you build on the container path.

The quick start states that the project requires Node.js 24.15.0 or newer but below 25, with pnpm 11.5.2 as the package manager. The Dockerfile at the root starts from `node:22.20.0`, which is outside that range, and it runs `npm install` rather than `pnpm install`, so the lockfile that the quick start pins with `--frozen-lockfile` is not the one the image uses. The container command is `npm run build:production`, which assumes the scripts are reachable through npm.

The compose file is equally minimal: a single `client` service built from that Dockerfile, with the port mapping 8090 to 8090, the project directory mounted over the image, and a named volume for `node_modules` so the installed packages survive a rebuild of the image. There is also a separate `compose.enterprise.yaml` for the enterprise variant. For a development loop this is a reasonable arrangement, but as a production image it is thin: a single service, no reverse proxy, no health check and no environment configuration beyond the mounted files.

Other things in the tree point to a project with serious tooling habits, and they are worth a look before you judge the work. There are multiple environment files for development, test and production, a `jest/` directory with a jest configuration, an `api/` directory for the local API, a `faker/` directory for demo data, a `deploy/` directory, a `.gitlab-ci.yml` alongside the GitHub workflows, a Sentry configuration, SonarLint and DeepSource configuration, a CHANGELOG.md, a SECURITY.md and a CONTRIBUTING.md.

On maintenance and licensing: the licence is MIT, which makes the code and the component package straightforward to use in a commercial product. The release history shows a major version bump on 2026-07-08 with v4.0.0, another on 2026-10-11 with v5.0.0, and a patch release v5.1.0 on 2026-10-12, with the last push on 2026-10-19. Two major versions in three months is a fast-moving project, so pin a version and read the changelog before upgrading, particularly for the component package, whose public API is consumed by other code.

## Conclusion

Pro React Admin suits a team that wants an admin front end with RBAC and audit pages already built, needs several branded applications from one dependency set, and is prepared to own the workspace configuration rather than consume a package. It is the wrong choice for a single small internal screen, where the multi-project, Module Federation and publishing machinery costs more than it saves. Verify three things before you start: that your machine has Node.js 24.15.0 or newer but below 25 with pnpm 11.5.2, that the Dockerfile base image is updated to match that requirement, and that the demo password mechanism, which generates a password in the browser, is replaced by a real tenant login before any deployment.

## FAQ

### What are the requirements to run Pro React Admin locally?

Node.js 24.15.0 or newer but below 25, and pnpm 11.5.2. After cloning, pnpm install --frozen-lockfile followed by pnpm start launches the demo app and a local API that starts at port 5200, with the web front end on 8080.

### What is the demo login for Pro React Admin?

There is no fixed shared password. On the signin page you click an account such as admin@test.com and the demo password for that account, generated in the current browser, is filled in automatically before you sign in and complete the slider verification.

### How do I publish the @w.ui/wui-react component package to npm?

Run the release check and the full preparation, log in with npm login, pack the package to a fixed artefacts directory, then publish that tarball with --ignore-scripts and verify it with npm view. The README states that a published version cannot be overwritten, so an update needs a version bump and the matching tarball name.

### What does Pro React Admin include besides a demo admin application?

A simplified enterprise entry with workbench, user, role and audit pages, multi-project builds, a Module Federation shell and remote example, and the standalone component package @w.ui/wui-react, which has its own Storybook with 157 entries.

### Does Pro React Admin need MongoDB to run locally?

No. The README states that development telemetry uses in-memory storage, so pnpm start works without MongoDB. The local API starts from port 5200 and increments if that port is already in use.

## Sources

- [License: MIT](https://github.com/wkylin/pro-react-admin/blob/main/LICENSE)
- [Project website](https://pro-react-admin.vercel.app/)
- [README](https://github.com/wkylin/pro-react-admin/blob/main/README.md)
- [Releases](https://github.com/wkylin/pro-react-admin/releases)
- [wkylin/pro-react-admin on GitHub](https://github.com/wkylin/pro-react-admin)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wkylin-pro-react-admin