TDesign Vue Next: Tencent's desktop component library for Vue 3

One install command and a per-component registration

The README's installation section is one line:

npm i tdesign-vue-next

The usage example then registers components individually rather than installing a whole plugin, which is the pattern that makes tree-shaking possible:

import { createApp } from 'vue';
import { Button } from 'tdesign-vue-next';

import 'tdesign-vue-next/es/style/index.css';

import App from './app.vue';

const app = createApp(App);
app.use(Button);

Two things in those eight lines decide your whole setup. Components come from named exports and go on one by one, so there is no global registration that silently pulls in the library. And the stylesheet is imported from `tdesign-vue-next/es/style/index.css`, which is ES module output rather than the CommonJS build. If you expect `import 'tdesign-vue-next/dist/style.css'` to work, it will not, and the fix is to copy the path in the README.

The README's feature list is short enough to quote accurately: desktop application interaction patterns, high quality components for Vue 3.x, a consistent API and UI with the TDesign libraries for other frameworks, dark mode and a customizable theme, and tree-shaking support. The cross-framework consistency is the claim that matters most, because it is the reason to pick this over any other Vue 3 library.

The README hands bundle choice to another document

Immediately after the usage example the README says the package provides kinds of bundles and links to a separate document in the tdesign repository for the differences between them. That is the single most consequential gap on the page for anyone evaluating the library, because bundle format determines how your build behaves and whether a style import resolves.

What the repository itself reveals fills in part of the shape. The root `package.json` is not the published package at all: it is named `tdesign-vue-mono`, marked `"private": true`, and its dependencies are all `workspace:^` references. So the repository root is a monorepo whose members are the things you actually install. The scripts confirm that structure with `build:vue` pointing at `internal/builds`, `build:nuxt` at `packages/tdesign-vue-next-nuxt`, and separate `dev:chat` and `build:chat` entries for `packages/tdesign-vue-next-chat`.

That means four related artifacts come out of one repository: the core library, a Nuxt integration, a chat component package, and an auto-import resolver that is built by `build:auto-import-resolver`. A reader deciding whether this fits a Nuxt project should know the Nuxt support is a first-class package rather than a community shim.

The `tsconfig.build.chat.json` and `tsconfig.build.vue.json` files sitting next to each other are the same story from the build side: the chat package and the Vue library are compiled as separate outputs with separate configurations.

A monorepo on develop, with pnpm 10 and Node 18 as the floor

The default branch is `develop`, not `main` or `master`. That matters more than it sounds, because `main` and `develop` typically hold different levels of stability and the branch you clone is the branch you build. The tree also carries `.node-version`, `.nvmrc`, `pnpm-workspace.yaml`, `pnpm-lock.yaml` and `commitlint.config.js` alongside `.husky/`, which describes a repository with a defined toolchain rather than a loose script collection.

The pinned toolchain is explicit. `packageManager` is set to `[email protected]`, and `engines` requires Node `>= 18`. The `postinstall` script runs `husky install` followed by a recursive postinstall across workspace packages, and there is a separate `pnpm:devPreinstall` script that runs `script/preinstall-tasks.js` before install. There is also an `init` script running `git submodule init` and `git submodule update`, alongside a `.gitmodules` file, which tells you that some part of the workspace is not vendored in the clone itself.

The quality gates are equally explicit. `lint` runs `tsc --noEmit` and then eslint across `.vue,.js,.ts,.tsx` under `./packages` with `--max-warnings 0`, meaning warnings are treated as failures. `test:vue` and `test:vue:update` delegate to a test package, and `lint:fix` is the autofix counterpart. For a component library, having the type check and the warning ceiling wired into one script is a reasonable signal about how the maintainers work.

One small oddity worth noticing: the tree contains `.agents/`, `.claude`, `.codebuddy` and `.cursor` directories at the root, which are configuration for AI coding tools committed alongside the source.

What a 1.20.x release actually changes

The most recent release is tagged `[email protected]`, published on 2026-09-17, eleven days before the last push on 2026-09-28. Reading its notes gives a fair sense of what a patch release in this library involves, and the answer is component-level correction rather than new surface.

The single feature is in `Form`: a `--last` marker added to the final form item so that margin styles apply correctly, which is the kind of fix that only makes sense once you have shipped the component to real users. The rest are corrections. `Breadcrumb` had its icon squashed by long text. `Icon` had wrong layer IDs in the raw usb icon set, which rendered wrongly in dark mode, and the fix came from the shared icons repository rather than this one. `Dropdown` had an `onClick` callback whose declared parameter type disagreed with runtime behaviour. `Menu` had a regression where some submenus failed to render after 1.20.7. `Swiper` had `current` being overridden by `defaultCurrent` when the value was `0`, plus a case where a function passed to `navigation` did not render custom navigation.

Two of those deserve emphasis for anyone upgrading. A regression introduced by the immediately preceding patch release is the normal cost of a cadence this fast, and a type that disagrees with runtime is the failure mode TypeScript users are least likely to catch on their own, since the compiler agrees with the annotation.

The cross-repository fix is also structural information. `Breadcrumb` and `Icon` are fixed in `tdesign-common` and `tdesign-icons`, so several components in this library are genuinely shared across TDesign's framework ports rather than reimplemented per platform.

Where it sits against Ant Design Vue, Element Plus and Naive UI

The related searches for this project surface Ant Design Vue, Element Plus and Naive UI, which is the comparison set a reader actually has. The difference is in the design system's reach, not in the component quality. Ant Design Vue is the Vue port of Ant Design and carries Ant's visual language and its documentation volume. Element Plus is the Vue 3 continuation of Element UI and has the largest installed base of the three. Naive UI is independent of any corporate design system and ships TypeScript throughout with its own theming model.

TDesign's argument is breadth of platform. The README links sibling libraries for Vue 2.x, for React, and for WeChat miniprogram, and claims a consistent API and UI across them. That claim is the thing to interrogate before committing: the fact that `Breadcrumb` and `Icon` fixes land in shared common packages shows the platforms are genuinely coordinated rather than independently maintained, which is a good sign. Whether the API surface stays identical across all four is a different question, and the README does not demonstrate it component by component.

For a team already building on another TDesign platform, this is the obvious choice. For a team starting fresh with no existing design system, the honest comparison includes documentation depth and the size of the community answering questions, and this library is behind Ant Design Vue on both.

Browser support is stated as Edge 84 or newer, Firefox 83 or newer, Chrome 84 or newer, and Safari 14.1 or newer, with a wiki page linked for details. Safari 14.1 is the binding constraint rather than the Chrome number, since it excludes anything older than roughly April 2021.

Editorial conclusion

Adopt TDesign Vue Next if you want a desktop-oriented Vue 3 component set that already matches a design system used by other TDesign frameworks, so moving a product between the React and Vue versions does not mean redoing every screen. The cost is a large surface with a fast release cadence, and 658 open issues against a repository whose last push was on 2026-09-28 tells you some of that churn will reach you. Verify the bundle you import first, since the README defers bundle differences to a separate document, then check that your Node version clears the `>= 18` engine requirement in the root `package.json` before you install anything from the monorepo.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Tencent/tdesign-vue-next on GitHub