VEUI: an enterprise Vue component library built on Light Design

What the library is, and where the design comes from

VEUI is a set of enterprise user interface components for Vue.js, and the design language behind it is named in the README, Light Design, the system used at Baidu. That detail matters more than it might appear, because a component library is mostly a set of decisions about how things look, and a library built inside a large company carries the assumptions that company's designers made. The project is published under the MIT licence, with the terms in a licence file at the root of the repository, and the documentation site carries both a Chinese and an English version, which tells you the intended audience is primarily Chinese-speaking teams with an international option. The positioning in the README is enterprise, and the feature list matches that word, with a focus on the parts of a component library that a large internal application needs and a small public one often skips.

Five packages, and why a design system ships separately

The repository is a pnpm workspace holding five published packages, and the split is the interesting part. The veui package is the component set itself. The babel-plugin-veui package is a Babel plugin, which in this ecosystem is the usual way to make a component library tree-shakable and to let a build pull in only the style and the code a page actually uses. The veui-loader package is a build loader for the same purpose at the bundler level. The veui-theme-dls package is the design language system, that is, the theming layer that turns the Light Design tokens into a theme a product can switch between, and veui-theme-dls-icons is the matching icon set. Separating the theme from the components is what makes the switchable themes in the feature list possible, and it also means a team can adopt the components and bring its own theme, or take the theme and write its own components.

The four features that are not standard

Most component libraries claim tree shaking, internationalisation and accessibility, so the interesting part is the qualifiers. The components are described as fully tree-shakable, which is a stronger claim than simply being importable, since it means the unused parts of the library leave the bundle. Internationalisation comes with compile-time optimisation, so the translation data is reduced at build time rather than shipped in full and filtered at run time, which is what you want when a product ships in several languages. Accessibility support is described as ARIA annotation with complete keyboard navigation, and the second half of that is the part that is usually missing, because a library can add the attributes without making every widget operable from the keyboard. The fourth is server rendering support with component-level critical CSS, which is a performance technique for extracting the styles needed for the first paint of a specific component, and it is a strong signal that the library was built for large applications with real server rendering rather than for demos.

Running the demo and building the packages

The contribution section is short, because the project uses pnpm as its package manager and a workspace layout. You clone the repository, install with pnpm and start the development server with pnpm dev, and the demo appears on a local port:

pnpm install
pnpm dev

The root scripts show how the pieces are assembled. The dev script runs the serve task of the veui package, the test script runs the tests of every package in the workspace, and the build script builds them all. There are also targeted builds for the component set, for the Babel plugin, for the loader and for the demo, and a separate script for building theme variants, which is what produces the different themes the switchable theming feature relies on. The toolchain in the root manifest is a mix of eras, with an older ESLint and Prettier alongside a newer Stylelint and Husky, and one dependency is patched in the repository itself, a PostCSS plugin for Rollup, which is a good sign of a project that fixes its problems locally rather than waiting for an upstream release.

How a release is cut

The release script is worth reading, because it explains how a monorepo of this kind keeps its versions in step. It runs a version bumper over the root manifest and every package manifest at once, with the commit, the push and the tag all part of the same command, and then it publishes every package to the registry with the public access flag, and finally it runs the sync script, which is the step that keeps derived files such as the version information in step with the sources. The result is that a consumer never sees a package released with a version that does not exist in the repository, and a new version of the theme package arrives together with the components that use it. The patched dependency and the sync script are the two details that reveal how much care goes into the plumbing, and they are also the two details a fork would have to keep working.

Where the project stands, and the alternative

The published releases stop in May 2024, with v2.17.9 the newest of the tags, while the root manifest sits at 2.17.10 and the last push to the branch is dated 2026-04-27. So the code is being maintained in some form while the packages on the registry are not being refreshed, and a reader should take the tag list, not the activity, as the version to plan against. That matters more than it might for a component library, because a team that adopts it is committing to a component set that will not gain new components at the pace the alternatives do. The comparison is with the larger Vue libraries, which bring a different design language, a much larger component catalogue and a bigger team, at the price of a heavier bundle and a steeper adoption. VEUI's argument is the opposite one, a focused enterprise set with tree shaking, a separated theme layer and serious server rendering support. A team that wants Light Design and can live with the catalogue is well served by it, and a team that wants the newest component every quarter is not.

Editorial conclusion

VEUI fits a Chinese enterprise team that wants a component set aligned with the Light Design language, that needs server rendering with critical CSS, and that values a small, tree-shakable bundle over a large design system. It does not fit a project that needs a large community, a long stream of new components, or a toolchain aligned with the current Vue release, because the published releases stopped in 2024 even though the repository is still touched. Before adopting it, check the version in the package manifest against the newest tag, run the demo locally to judge the visual language, and confirm that the component coverage matches the screens you actually have to build.

Frequently asked questions

Official sources

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