Inside vue-pure-admin's package.json: what the scripts reveal about the template

A single preinstall hook blocks npm and yarn

package.json carries one line that decides which package manager you are allowed to use: `"preinstall": "npx only-allow pnpm"`. It runs before dependencies are resolved, so a plain `npm install` inside this directory exits with an error instead of creating node_modules. That is a guard, not a preference, and it has consequences worth knowing before you wire the template into an existing pipeline. Any CI job, container base image, or onboarding script that defaults to npm fails at the install step rather than at build time, which puts the first failure in a fresh environment where nobody knows the project yet. The top level of the repository holds pnpm-lock.yaml and pnpm-workspace.yaml, and no package-lock.json or yarn.lock, so nothing in the tree gives npm a resolution to work from. The one place npm is the documented tool is the global scaffold, installed before any project exists:

npm install -g @pureadmin/cli

After that, project creation is an interactive picker rather than a flag:

pure create

Cloning the repository and installing from inside the checkout is a pnpm only operation. If your pipeline cannot be changed to pnpm, this template is the wrong starting point, and you will discover that at preinstall rather than in prose.

Dev and build raise the Node heap, staging and report do not

Two scripts wrap Vite in an explicit heap ceiling and two others do not. `pnpm dev` runs `NODE_OPTIONS=--max-old-space-size=4096 vite`, and `pnpm build` runs `NODE_OPTIONS=--max-old-space-size=8192 vite build`. The staging and report scripts call Vite with no such flag: `"build:staging": "rimraf dist && vite build --mode staging"` and `"report": "rimraf dist && vite build"`. Read together, those four lines say that memory pressure is a known problem for the commands people run daily and simply left in place for the two you reach for when a build already looks wrong. A staging build in a project that has grown past the default Node heap can die with an out of memory error where the same source builds fine through `pnpm build`, and the only difference is a flag. On a small container the 8192 megabyte ceiling is also a ceiling you have to be able to grant, so the Docker build stage needs a host that can back it. If you plan to run staging builds in CI, that is a runner setting to verify early rather than discover later.

Only pnpm build deletes dist and writes a version file

The build script is a three part chain: `rimraf dist && NODE_OPTIONS=--max-old-space-size=8192 vite build && generate-version-file`. Two of those steps are easy to miss. First, rimraf wipes the output directory before Vite starts, so an interrupted or failing build leaves you with no dist at all rather than with the previous one still in place. That is clean, but it makes a build an all or nothing operation, and any deploy step that assumes a prior artifact survives a failed run will find the directory empty. Second, generate-version-file runs after Vite finishes and appears in no other script. `preview:build` gets it only because it delegates to `pnpm build`; `build:staging` and `report` stop at vite build. A staging bundle therefore does not get a freshly generated version file. If you stamp build information into the interface so a deployed bundle can be identified, verify that the path you actually use in production is the one that writes it, because the other two quietly skip that step.

The Dockerfile builds from a China mirror against a frozen lockfile

The image is a two stage build. The first stage is `node:20-alpine`; it enables corepack, activates the latest pnpm, and then runs `npm config set registry https://registry.npmmirror.com` before it touches dependencies. That registry line is the detail to notice. The container resolves packages from a China npm mirror rather than the default, so build speed and availability depend on reaching that mirror, and a build run on a network outside that region pulls from a different dependency source than a local pnpm install does. Dependencies are installed with `COPY .npmrc package.json pnpm-lock.yaml ./` followed by `pnpm install --frozen-lockfile`, which keeps layers cached correctly and also means the build stops dead if the lockfile and the manifest disagree. Because `clean:cache` deletes pnpm-lock.yaml outright, anyone who runs it to fix a broken install regenerates that lockfile, and a regenerated lockfile out of step with package.json is exactly what frozen mode is built to catch. The second stage swaps to `nginx:stable-alpine` and nothing else.

The runtime image is nginx with files and no server

`FROM nginx:stable-alpine` and `COPY --from=build-stage /app/dist /usr/share/nginx/html` are the whole runtime. The container exposes port 80 and runs `nginx -g "daemon off;"`. Nothing in that stage starts an application, opens a database connection, or answers anything but the static files Vite produced. That is exactly what the documented commands are for, building an image and running it to look at the interface in a browser:

docker build -t vue-pure-admin .

docker run -dp 8080:80  --name pure-admin vue-pure-admin

The trailing dot in the build command selects the Dockerfile in the current path. The run command maps container port 80 onto host port 8080, names the container pure-admin, and after both commands `http://localhost:8080` shows the result. Take this Dockerfile to production and you inherit an image that cannot serve a single API call on its own, so a separate service has to exist and the front end has to be pointed at it. There is also no configuration stage after the copy. The repository carries .env, .env.development, .env.production, and .env.staging files, which Vite reads while building, and the running container has no documented way to change a value after the image exists. Anything that must differ per environment costs a rebuild.

svgo, clean:cache, and eslint all rewrite your working tree

The maintenance scripts in package.json are not read only operations, and each one reaches further than its name suggests. `svgo` is `svgo -f . -r`, with the current directory as its only argument, so running it optimizes every SVG it can find anywhere in the checkout and rewrites those files in place, including assets you did not mean to touch and anything vendored into the tree. On a fork that has become a product, that produces a diff far larger than your change and a review nobody wants. `clean:cache` is blunter: it runs `rimraf .eslintcache && rimraf pnpm-lock.yaml && rimraf node_modules && pnpm store prune && pnpm install`, so clearing a cache also discards the file that pins your dependency versions, and the frozen install in the Dockerfile will then reject the tree. The lint chain is the third of these. `pnpm lint:eslint` runs `eslint --cache --max-warnings 0 src mock build --fix`, where zero allowed warnings turns every style note into a failed command, and the three path arguments mean nothing outside src, mock, and build is checked. The full `pnpm lint` adds prettier and stylelint, and husky runs from a prepare script.

Three changelogs, no migration notes, and IE in the unsupported column

Version information is easy to find and thin on detail. Three changelog files sit at the top level: CHANGELOG.md, CHANGELOG.zh_CN.md, and CHANGELOG.en_US.md, and the README's changelog section links only the Chinese one. The releases listed are v7.0.0 on 2026-04-07, v6.3.0 on 2025-12-10, and v6.2.0 on 2025-10-16, and package.json declares version 7.0.0. The last push to the default main branch is dated 2026-10-12, so the tree is current rather than abandoned. There is no upgrade command among the scripts, so a project that forked this template before 7.0.0 has to audit the gap itself, starting from the changelogs. The browser story is stated more directly. The support table marks Internet Explorer as unsupported while listing Edge, Firefox, Chrome, and Safari, and the authors recommend Chrome, Edge, or Firefox for local development, describing Firefox as the smoothest of them for animations.

This checkout is the full version, and the maintainers point elsewhere

The install section names this repository as the full version and then routes real work somewhere else, offering a reduced version for actual projects in two flavors, one without internationalization and one on an i18n branch. The bundle size figures that circulate with the project, under 2.3MB with element-plus imported globally and under 350kb with brotli compression plus a CDN in place of local libraries, belong to that reduced version rather than to this checkout, and the reduced repositories are meant to stay in step with the full code permanently. Desktop shells live in their own repositories too, one built on Tauri and one on Electron. A .gitpod.yml sits at the top level with a Gitpod button that opens the project in a hosted editor, and the documentation lives off the repository at pure-admin.cn with a separate site for the @pureadmin/utils package. Cloning is documented from two remotes, and the steps after a clone are short:

git clone https://github.com/pure-admin/vue-pure-admin.git

cd vue-pure-admin

pnpm install

pnpm dev

pnpm build

The practical consequence for an adopter is that the demo pages, the mock directory, and the locales directory are scaffolding to delete, and that any size claim repeated from this repository belongs to another one.

Editorial conclusion

Use vue-pure-admin when your team already works in pnpm and wants a Vue 3 and Element Plus shell with a mobile view, a dark theme, a hosted preview, and a Docker path that takes two commands. Skip it when your pipeline is locked to npm, when Internet Explorer users are in scope, or when you expect a backend, because the runtime image serves files and has no server behind it. Before building on it, read the 6.x to 7.0.0 changes yourself, since no upgrade script is provided, and confirm that the build script you use in production is the one that writes the version file.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. pure-admin/vue-pure-admin on GitHub
4. README
5. Releases