# vue-devui and the case for shipping a whole design language with Vue 3

> Vue DevUI is a Vue 3 component library of 55 components built on the DevUI Design language, with TypeScript types, Nuxt 3 support, on-demand import, internationalization and seven built-in themes. It is a community-run project on a dev branch whose last tagged release predates its last push by more than a year.

**DevCloudFE/vue-devui** — UI components based on Vue3 and DevUI Design

- Repository: https://github.com/DevCloudFE/vue-devui
- Website: https://vue-devui.github.io
- Stars: 1,167 · Forks: 283
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/devcloudfe-vue-devui

## A component library that carries a design language with it

Vue DevUI is a Vue 3 component library based on DevUI Design. The design system it implements lives at devui.design, and the documentation site is at vue-devui.github.io.

The interesting choice is that this is a design system port rather than a generic component set. Most Vue libraries give you buttons, inputs and tables in a neutral style, and the visual identity is your problem. Vue DevUI ships 55 components together with the DevUI Design language, including seven built-in themes named Galaxy, Sweet and Provence among them, plus the ability to customise the theme yourself. The pitch in the feature list is a set of components that are simple, easy to use and flexible, and the real product is the pairing of components with a coherent look.

That pairing is the whole value proposition and also the whole constraint. A team that adopts it gets a consistent interface quickly, and inherits a specific visual language, a specific component API and the maintenance burden of keeping up with a community project. A team that wants its own design has to work against the library rather than with it.

The project is organised as a pnpm workspace with a packages/ directory, and it is run by a community rather than a company. The maintainer list in the README runs to twenty names, and the criteria for outstanding contribution are spelled out, ten or more merged pull requests, more than ten approved review opinions, and constructive optimisation advice. This is a project run on enthusiasm, which is a strength for consistency of taste and a risk for continuity of maintenance.

## One dependency, and a stylesheet you must import yourself

Installation is a single package, available through npm, yarn or pnpm:

```sh
npm install vue-devui --save
```

The yarn and pnpm equivalents are yarn add vue-devui and pnpm add vue-devui. There is no plugin to configure, no build step of your own and no provider to register.

The one thing the README is emphatic about is the stylesheet. Importing the library is not enough on its own, because the components need the CSS that ships with the package. The setup in main.ts looks like this:

```ts
import { createApp } from 'vue';
import App from './App.vue';

// Import Vue DevUI component and style
import DevUI from 'vue-devui';
import 'vue-devui/style.css';

createApp(App).use(DevUI).mount('#app');
```

So the library registers itself as a Vue plugin through use(DevUI), and a separate import of vue-devui/style.css brings in the styles. Forgetting that second line is the classic failure mode here, and it produces an application where the components render but look wrong, which is a confusing symptom for anyone who did not read the setup section carefully.

After that, components are used as tags in the template, with a d- prefix:

```vue
<template>
  <d-button>Button</d-button>
</template>
```

The d- prefix is a small but consequential detail. It keeps the library's elements out of the global namespace, so a d-button cannot collide with a button of your own, and it makes the origin of any element obvious when you read a template six months later.

## TypeScript, Nuxt 3, on-demand import and i18n in one library

The feature list is short, and every entry is a decision a team has to make at some point.

TypeScript support matters more than it used to, because the components carry types and your IDE can check a prop name. For a library with 55 components and a large prop surface, that is where most of the friction would otherwise live.

Nuxt 3 support determines whether the library works in a server-rendered application at all, which is a question many component libraries leave open for long stretches.

On-demand import is a bundle size decision. A component library that pulls its whole catalogue into every build is a common complaint, and the ability to import only what a route uses is what keeps the payload proportional to the screen. The feature list states the support, and the practical detail of how to configure it lives in the documentation site rather than in the README.

Internationalization is the fourth, and it is the one most libraries skip. A component library that ships untranslated strings forces every consumer to fork the source or to accept English labels in a product for another market. Vue DevUI declares support for i18n, with the strings available for translation.

The combination is the interesting part. A library can be excellent at components and weak at types, or good at types and awkward in Nuxt, and the set here is coherent. The count, 55 components, is also worth pausing on, because it is large enough to cover a real product surface and small enough to stay reviewable, unlike a collection that ships hundreds of rarely used widgets.

## Seven themes, and the option to replace them

Theme customisation is listed alongside the seven built-in themes, Galaxy, Sweet and Provence being three of the names. That combination tells you how the theming is built: there is a set of curated palettes that work out of the box, and a mechanism to define your own.

The distinction between a theme and a design token set is the thing to check. A theme that is a single colour variable is easy to adopt and hard to make distinctive. A token based system, where spacing, radius, typography and a palette are separate variables, is what lets a product team keep the component behaviour and still own the look.

The repository gives a hint about the tooling: the root package.json exposes a build:lib:theme script alongside build:lib, which suggests the theme is compiled as part of the library rather than applied by a runtime stylesheet swap.

The stylesheet import in the setup makes the same point from the consumer side. You import vue-devui/style.css once, at application startup, so there is one stylesheet rather than a component-scoped style pipeline, which is simpler but gives you less room to override internals.

## A dev branch, a gap in the version numbers, and a 2025 release

The repository defaults to the dev branch rather than main or master, and the release history is not a simple sequence. The published tags are v1.6.33 from 2025-06-17, v1.6.29 from 2024-12-11 and v1.6.28 from 2024-12-01, so the version numbers jump and the spacing between releases is irregular.

The repository itself is not archived and the last push was on 2026-08-26, which is well after the newest tag. In other words, work continues on a branch whose published counterpart stopped more than a year ago. For a component library, that combination is worth understanding before you commit: the npm package you install is the older, tagged artefact, while the branch contains the current state of the work.

That is not automatically a problem. Component libraries in a mature state change slowly, and a stable tag that a team can pin is often preferable to the tip of a branch. The problem is knowing which is which, and the README does not explain the release flow, so a team that reads the repository for the version and installs something else will not know why a component behaves differently than the source suggests.

The development setup in the README assumes pnpm:

```sh
git clone git@github.com:DevCloudFE/vue-devui.git
cd vue-devui
pnpm install
pnpm dev
```

The site then runs at http://localhost:3000/, and the root package.json shows the workspace shape, with dev, dev:site, build, build:lib, build:lib:theme and test each filtered to the vue-devui package, and a scripts entry powered by better-scripts for the rest of the available commands.

## The linting setup tells you how the project is maintained

The root package.json is a small lesson in how a component library stays consistent. Husky installs the git hooks on prepare, lint-staged runs on precommit, and the lint-staged configuration is split by file type: eslint with --fix for vue, js, ts, jsx and tsx files under packages, and stylelint with --fix for scss and css. Commit messages go through commitlint, and .ls-lint.yml enforces file and directory naming with ls-lint.

The tool versions are where the story gets dated. The dev dependencies pin eslint at version 7, eslint-plugin-vue at 7, stylelint at 13 with the scss configuration, @types/node at 16, and commitlint at 11. These are several major versions behind where those tools now sit, and a project that wants to move would have to work through the plugin peer dependency changes that come with it.

The style tooling is more specific than that. stylelint-config-standard and stylelint-config-recommended-scss together mean the stylesheet is linted against a standard config and a separate scss ruleset, which is the part that catches the mistakes you actually make in component styles, such as nesting depth and shorthand properties.

For a community project, this is a sensible amount of rigour. What it signals, though, is that the project is being maintained by people who know the toolchain they set up rather than by people continuously upgrading it, which is consistent with the release pattern and with a codebase where the components themselves are the stable part.

## MIT, and what a community library owes you

The licence is MIT, with the text in the LICENSE file at the root of the repository. That is about the most permissive arrangement a component library can have, and it removes the usual question about whether a design system can be dropped into a commercial product without a licensing review. The licence file sits alongside a CODE_OF_CONDUCT in two languages, a CONTRIBUTING guide and the all-contributors configuration that generates the contributor table in the README.

The contributing guide lives at vue-devui.github.io/contributing/, and the README is explicit about what a contribution is expected to look like. It is a teaching oriented project as much as a code one, and the four reasons the README gives for joining are all about learning: the Vite, Vue 3, TypeScript and JSX stack, how to design and develop UI components, programming practice, and meeting people who like open source.

That framing is a fair description of how a community library runs, and it has consequences for an adopter. There is no vendor behind it, no support contract and no roadmap commitment from an employer. What there is, judging from the maintainer list and the outstanding contribution criteria, is a group of people with the taste and the time to keep the design coherent.

If your product depends on the library, the sensible reading of the maintenance record is this: the components are stable, the tooling is dated, the published npm version trails the branch by more than a year, and the project depends on a volunteer group. None of that makes it a poor choice for a product that has settled on a design, and all of it argues for pinning a version and keeping the component usage shallow enough that you could replace it.

## Conclusion

Adopt vue-devui if your team wants a coherent, ready made Vue 3 interface without designing tokens, components and states from scratch, and if shipping a design system you maintain yourself is not part of the plan. Do not adopt it if your product needs a bespoke visual language, because a component library's value comes precisely from the constraints it imposes. Verify three things first: that the version you install on npm matches the components you plan to use, since the published release trail stops at v1.6.33 while the default branch has moved on, that the on-demand import and internationalization support work with your bundler, and that the theme you pick suits the density your data needs. The last push was on 2026-08-26 and the project is licensed under MIT.

## FAQ

### How do I install and use vue-devui in a Vue 3 project?

Run npm install vue-devui --save, then in main.ts import DevUI from 'vue-devui', import 'vue-devui/style.css', and call createApp(App).use(DevUI).mount('#app'). Components are then used as tags such as d-button in your templates.

### How many components does vue-devui ship?

The feature list states 55 high-quality components, covering the usual interface surface, along with TypeScript support, Nuxt 3 support, on-demand import, internationalization and theme customisation.

### Does vue-devui come with themes?

Yes. It ships seven built-in themes, including Galaxy, Sweet and Provence, and also supports theme customisation so a team can define its own.

### How do I run the vue-devui documentation site locally?

Clone the repository, run pnpm install and pnpm dev, then open http://localhost:3000/. Other available commands are listed with pnpm scripts, and the root package.json filters dev, dev:site, build, build:lib, build:lib:theme and test to the vue-devui package.

### What is the latest vue-devui release?

The newest tag is v1.6.33 from 2025-06-17, preceded by v1.6.29 from 2024-12-11 and v1.6.28 from 2024-12-01. The repository is not archived and the last push was on 2026-08-26, and the default branch is dev rather than main.

### What licence is vue-devui released under?

MIT, with the licence text in the LICENSE file at the root of the repository. The project is maintained by community members, with a contributing guide and a code of conduct published alongside it.

## Sources

- [DevCloudFE/vue-devui on GitHub](https://github.com/DevCloudFE/vue-devui)
- [License: MIT](https://github.com/DevCloudFE/vue-devui/blob/dev/LICENSE)
- [Project website](https://vue-devui.github.io)
- [README](https://github.com/DevCloudFE/vue-devui/blob/dev/README.md)
- [Releases](https://github.com/DevCloudFE/vue-devui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/devcloudfe-vue-devui