vue-element-admin: i18n is listed as a feature and removed from master, and the last release is from 2020

The last release is dated 2020 and the last commit is dated 2024-10-24

Two dates decide how you should read everything else in this file. The most recent release is 4.4.0, titled Update to vue-cli@4, published 2020-06-21. Before that came 4.3.1 on 2020-06-18 and 4.3.0 on 2020-06-08, titled Change Node Sass to Dart Sass. The last push to the default branch is dated 2024-10-24. So the newest tag is more than six years old, and the newest commit is a little under two. The three most recent releases are all within a two-week window in June 2020, which tells you the release train stopped there. Consequence for a reader: the file describes itself as built on the newest development stack of vue, and that claim was true of a 2020 stack. Nothing after the 4.4.0 tag changed the toolchain, so the toolchain you inherit is the one those three June 2020 releases settled on.

The feature list advertises I18n and the notice above it says master removed it

The Introduction says the project has a built-in i18n solution. The Global Features list includes I18n as a checkbox item. Then, in bold partway down the front page, the file says that after the v4.1.0+ version the default master branch will not support i18n, and directs you to a separate i18n branch that will keep up with the master update. Two of those three statements cannot be true of the same checkout. Consequence for a reader: someone reading top to bottom builds an i18n layer, then finds the i18n branch is the only place it exists, and the maintenance promise for that branch is a single unversioned sentence rather than a release. The feature list is a description of the project's history, not a description of what master contains, and nothing in the file marks which features survived the v4.1.0 cut.

One paragraph says IE is unsupported and the table at the bottom lists IE10 and IE11

The front page says the project does not support low version browsers, naming IE as the example, and tells you to add polyfill by yourself. The Browsers support section at the foot of the same file says Modern browsers and Internet Explorer 10+, and the table underneath gives IE10, IE11 and Edge in the first column, then last 2 versions for Firefox, Chrome and Safari. Three problems live in that table. The headline and the notice contradict each other about the same browsers. The three modern columns are not versions at all but a moving rule, so the table cannot be true of any particular day. And the IE column names specific versions while the notice tells you to bring your own polyfill. Consequence: the support statement a reader needs is the one that is self-contradictory, so you have to decide for yourself which browsers your users have and supply the compatibility layer yourself.

Twenty seven runtime dependencies, every one pinned to an exact version

The dependencies block uses exact pins throughout, with no caret and no tilde, so a fresh install reproduces one specific tree.

"axios": "0.18.1",
"element-ui": "2.13.2",
"vue": "2.6.10",
"vue-router": "3.0.2",
"vuex": "3.1.0"

Several of those pins are the only thing holding a single feature together. fuse.js 3.4.4 backs the search, driver.js 0.9.5 is the onboarding tour, vue-count-to 1.0.13 is the count-up widget, sortablejs 1.8.4 does the drag ordering, dropzone 5.5.1 does the upload and codemirror 5.45.0 is the code editor. Consequence for a reader: exact pins give you a reproducible build and no upgrade path, so a vulnerability fix or a needed feature in any one of those packages means you fork a pin yourself. core-js sits in the same block at 3.6.5, so a polyfill library is already a runtime dependency while the front page still asks you to add polyfills by hand.

Four environments are named, three env files exist, and two scripts build them

The feature list names four build environments: Develop (dev), sit, Stage Test (stage), and Production (prod). The root holds three environment files, .env.development, .env.staging and .env.production. And the scripts offer two builds.

"build:prod": "vue-cli-service build",
"build:stage": "vue-cli-service build --mode staging"

Read those three lists against each other. The stage script passes a mode that names .env.staging, and the production script passes no mode at all, so it relies on the default. There is no build script for `sit` and no .env file named for it, which means the fourth environment in the feature list is either driven entirely by injected variables or is a name that outlived a removal. Consequence for a reader: the environment matrix is documented in one place and implemented in another, and the mismatch is only visible by counting files, so anyone setting up a fourth deployment target is writing the configuration the template does not ship.

Lint is scoped to src, and the unit test throws away the jest cache first

The check scripts are short and the lint target is narrower than the repository.

"lint": "eslint --ext .js,.vue src",
"test:unit": "jest --clearCache && vue-cli-service test:unit",
"test:ci": "npm run lint && npm run test:unit"

The lint command passes src as the only path, so the mock directory, the build scripts, the tests directory and the plop templates sit outside every lint pass, even though mock data definitions and build scripts are ordinary JavaScript that could fail. The unit script begins with jest --clearCache, so the cache is discarded before every run and the test suite starts cold each time. The combined test:ci runs lint first and unit second, and since lint cannot see outside src, a change that breaks the build tooling passes CI. Consequence: the green check covers the application source and little else, which is a narrower guarantee than the script name suggests.

Getting out of the old stack means switching to a branch named tag/3.11.0

There is no migration guide in this repository. The file says the current version is v4.0+ built on vue-cli, and then offers the old stack as a branch: if you want to use the old version you can switch branch to tag/3.11.0, and it does not rely on vue-cli. The path away from the previous generation is therefore a branch whose name is formatted like a tag, carrying a version number lower than any of the current releases, and it is reachable by name rather than by a documented upgrade procedure. The root also has jest.config.js, babel.config.js, postcss.config.js and vue.config.js, so the configuration surface itself changed with the toolchain. Consequence: an application already on 3.11.0 has no in-place upgrade described here, only a fork that has to be brought forward file by file, and the two generations differ in the build system, not just in versions.

A Vue-only template sells a Java backend with a coupon code

The Sponsors section names two companies. Akveo is described as Get Java backend for Vue admin with 20% discount for 39$, with a coupon code spelled out in the file. Flatlogic is described as admin dashboard templates made with Vue, React and Angular. The sponsor table markup above them is commented out in the file, so the rendered page shows the two entries as prose rather than as a sponsor block. Elsewhere the repository presents itself as a production-ready front-end solution for admin interfaces with preview, documentation, wiki and a Gitee mirror for users in China, while the homepage field is empty and the preview URL is carried inside the description string instead. Consequence for a reader: the backend you would need to make the demo real is something this repository does not contain and instead points at a paid product, and the localization story is four full README files at the root that have to be maintained in parallel.

Editorial conclusion

vue-element-admin is worth reading as a reference implementation of an enterprise admin shell, and is a poor foundation for a new project unless you are committed to Vue 2 and to owning the dependency upgrades yourself. Verify the branch you are on before you start, because the i18n notice means master and the i18n branch are not the same codebase. Before you build on it, check the dates, expect to replace the pinned runtime dependencies, and plan for the old pre-vue-cli stack to live on a separate branch rather than in a migration path you can follow.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes