HeyUI.ext: a Vue 3 component toolkit maintained as a fork of HeyUI

What HeyUI.ext is, and why the fork exists

HeyUI.ext is a Vue 3 component toolkit distributed on npm under the name heyui.ext. The package description in package.json reads "UI Toolkit for Web, Vue3.0.夏悸增强bug修复扩展版本", which identifies it as a fork of the original HeyUI project with bug fixes and enhancements layered on top. The repository topics list the component families you would expect from an admin-oriented library: table, form, select, autocomplete, datepicker, datetimepicker, modal, tree, validator and i18n. The licence is MIT.

The audience is narrow and worth stating plainly. This is not a general-purpose design system for public-facing marketing pages. The component list, the Less theming layer and the admin template link point at internal dashboards, back-office tools and form-heavy applications where a team wants many widgets from a single dependency. If you are building a Vue 2 application, the peerDependencies field in package.json requires vue ^3.2.41, so the current npm package is not the artifact for you even though the original HeyUI line was Vue 2.

The fork framing matters because it explains the maintenance shape. The README opens with a changelog rather than an introduction, and the version history mixes entries from the upstream HeyUI 2.x line with fork-specific releases such as 2.3.7, which links to a comparison against v1.26.1 on the btboys/heyui repository. The last push to the repository was on 2026-04-07, so the project is not abandoned, but the most recent npm release listed in the README is from 2020, and that gap is the single most important thing to check before you build on it.

How the toolkit is wired: Vite, Less themes and a Vue plugin

The build chain is visible in package.json and the repository layout. Vite is the bundler (vite ^3.2.7 with @vitejs/plugin-vue), and the build scripts split into three targets: npm run build for the main bundle, npm run buildcom for components, and npm run buildlang for language files. The published package entry points are ./dist/heyui.js for CommonJS consumers and ./dist/heyui.esm.js for module consumers, and the files array ships dist, lang, themes, lib, README.md and simple.html.

Theming is handled through Less rather than CSS variables. There is a themes directory at the repository root, and a varless script converts themes/var.less into both themes/var.json and themes/var.js using the lessto tool, which suggests the theme variables are consumed both by the stylesheet pipeline and by JavaScript that needs the same values. That is a real architectural choice with consequences: your build must be able to compile Less, and the import path in the README points at a .less file rather than a compiled stylesheet.

Internationalisation is a first-class concern rather than an afterthought. The lang directory is a published artifact with its own build script, and i18n appears in the repository topics. The runtime dependency story is thin: peerDependencies lists manba ^1.3.3 alongside Vue, so manba is expected to be present in the consuming application rather than bundled. Everything else in the dependency list is devDependencies for linting, formatting, release tooling and the build itself.

One structural detail is worth flagging. The package.json includes a cp script that copies dist, lib, lang, themes and package.json into a ./heyui-website/heyui directory. That is a publishing convenience for the documentation site, not something a consumer runs, but it tells you the docs site is served from a sibling checkout rather than from the package itself.

Installing heyui.ext and rendering a first component

The README gives a two-step install. The package name is heyui.ext, not heyui, so the install line is specific.

npm install heyui.ext --save

The README's "Start" section shows the advanced registration path for a Vue 3 application. It creates the app with createApp, imports the library default export, imports the Less theme entry, registers the plugin with app.use, and mounts. The README example omits the const app = createApp(App) line, so you supply your own root component.

import { createApp } from 'vue';
import heyui from 'heyui.ext';
require('heyui.ext/themes/index.less');

app.use(heyui);
app.mount('#app');

After app.use(heyui) the components are registered globally, so you can use them in templates without importing each one. What you should see is your root component rendering with HeyUI styling applied; if the theme import fails, the components render unstyled rather than throwing, which is the failure mode to watch for first.

For working on the library itself rather than consuming it, the README's Development section is two commands. npm install fetches dependencies and npm run build produces the bundle. The package.json adds npm run dev for the Vite dev server and npm run create for the component scaffolding script in scripts/create.js. There is no documented test command in the scripts block, which is a gap worth noting if you plan to contribute patches.

The README is a changelog, and that is the main limitation

The most honest thing to say about HeyUI.ext is that its README does not function as documentation. It opens with a changelog, then a Documentation pointer to heyui.top, then install and start snippets, then a browser support line. There is no component reference, no prop table, no list of slots or events, and no migration guide. The documentation lives at v2.heyui.top, and the README's only job is to point there.

That has a practical cost. When the changelog says Select gained a filter attribute for custom filtering, or that AutoComplete gained deletable, or that Confirm gained cancelText and okText, you cannot confirm the accepted values of those props from the README. You either read the source under src/ or you read the site. For a component library, the prop surface is the API, so the API reference being off-repository is a real friction point.

Browser support is stated as "Modern browsers and Internet Explorer 11+". That claim sits awkwardly next to a Vite 3 build and a Vue 3 peer dependency, since Vue 3 itself dropped IE11 support. Treat the IE11 line as inherited from the original HeyUI README rather than as a tested statement about the current fork, and verify it yourself if legacy browser support is a requirement.

The release history is the other limitation. The README's most recent release entries are 2.3.7 from 2024-03-19 and 2.2.0 from 2023-02-08, while the Recent releases list in the repository metadata stops at v1.26.1 from 2020-08-24. package.json reports version 2.4.3. Those three sources do not agree, and nothing in the repository explains why. Before adopting, confirm which version npm actually resolves.

HeyUI.ext against Element Plus and Ant Design Vue

The obvious alternatives for a Vue 3 admin interface are Element Plus and Ant Design Vue. The difference is not feature coverage, since all three ship tables, forms, selects, date pickers, modals and validation. The difference is governance and documentation.

Element Plus and Ant Design Vue are the primary projects of their respective organisations, with component documentation maintained in the same repository as the code and release cadence driven by a team. HeyUI.ext is a personal fork. The README's own changelog links fork commits to btboys/heyui, and the upstream heyui/heyui repository is a separate entity. That means the fork's future depends on one person's continued interest, and upstream fixes do not automatically arrive.

The second difference is the styling layer. Element Plus and Ant Design Vue both expose theming through CSS custom properties, which lets you override values at runtime without recompiling. HeyUI.ext uses Less variables converted by a build script into JSON and JS. That is workable and arguably more flexible at compile time, but it means a theme change is a build change, and your bundler has to understand Less.

The third difference is ecosystem gravity. Choosing Element Plus or Ant Design Vue buys you a larger pool of third-party templates, blog posts and Stack Overflow answers. Choosing HeyUI.ext means the v2.heyui.top documentation and the src/ directory are your reference. If your team already knows the original HeyUI API and wants to move to Vue 3 with minimal relearning, that trade is defensible. If you are starting fresh with no prior HeyUI exposure, the documentation gap is hard to justify.

Maintenance, versioning and what the MIT licence lets you do

The repository is not archived, and the last push was on 2026-04-07, so there is recent activity. That is the strongest maintenance signal available, and it is a weak signal on its own: a push can be a documentation tweak or a dependency bump. The Recent releases list ends at v1.26.1 from 2020-08-24, while the README changelog carries entries into 2024 and package.json declares 2.4.3. Reconcile those before you plan an upgrade path, because a version you cannot pin confidently is a version you cannot upgrade deliberately.

Upgrade cost is dominated by the theming layer. Because themes are Less variables compiled at build time, a major version that renames a variable breaks your build rather than degrading gracefully. The varless script in package.json regenerates themes/var.json and themes/var.js from themes/var.less, so any local theme override you maintain against those generated files needs to be regenerated after an upgrade. There is no documented codemod or migration tool in the repository.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is permissive enough for closed-source internal products. Two caveats are worth stating without giving legal advice: the fork inherits from an MIT-licensed upstream, so upstream notices should remain intact, and the repository contains a commercial case study link in the README that is a reference to a product built with the library, not a licence term. Read the LICENSE file in the repository rather than relying on the npm badge.

Editorial conclusion

Adopt HeyUI.ext if you are building an internal admin interface on Vue 3 and want a broad component set from one package, and if you accept that the README is closer to a release log than a manual, so you will read src/ and the v2.heyui.top docs to learn component props. Do not adopt it if you need a documented Vue 2 path (the npm package targets Vue 3), a published upgrade guide, or a guarantee that the fork's maintainer keeps pace with upstream. Before committing, verify three things: that npm install heyui.ext --save resolves a version, that your bundler handles the Less import at heyui.ext/themes/index.less, and that the components you depend on exist in the current package rather than only in the changelog.

Frequently asked questions

Official sources

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