TDesign: one design system, eleven repositories, and a weekly release tag

The main repository is documentation and tooling, not components

This repository is the hub, and reading its own root manifest makes that clear. It is marked private, so nothing is published from it, and its only runtime dependency is a syntax highlighting library used by the documentation site. Everything else in the manifest is tooling: a pinned version of the workspace package manager with a lower bound declared in its engines field, scripts that run the component playground, the documentation site, and a theme generator, each scoped with a filter to a particular workspace package, and a prepare script that installs the git hooks. There is also a service directory and a packages directory. So the picture is a monorepo whose job is the design system's shared surface, documentation, and theme tooling, with the actual component libraries maintained elsewhere. If you are looking for the component code, this is the wrong clone.

Eleven repositories, and one row points at the wrong one

The repository list is grouped into four tables and the grouping is the design. Desktop components are three libraries: one for the current Vue, one for React, and one for the older Vue 2 line. Mobile components are five: the WeChat mini program library, mobile libraries for Vue 3 and for React, a Flutter library published on a package registry rather than npm, and a cross-platform mini program library. Shared are three: this main repository, an icon set kept as a monorepo of its own, and a common package holding shared style and utilities. Starter kits are five, one command-line tool and four project templates. Reading down the mobile table, one row is worth pausing on: the cross-platform mini program entry links its GitHub column to the mini program repository rather than to its own, while its package column points at a scoped npm name. So the link table, which is the page's only navigation, has a row where the repository link and the package link disagree about what the thing is.

Weekly tags whose titles carry a different date

The three most recent releases are all titled as weekly releases with an ordinal week label, and each tag is named with a date-shaped version. The two do not line up. One tag is named for a late-September date while its title names the fourth of September; the next is named for a Monday in that week and its title names the third; the third is named for a Monday and its title names the second. And the publication timestamps are a third set of numbers again, running a few days after the dates in the names. So there are three date-like values per release, none of which agree. For anyone automating a release check that reads a version string, the practical consequence is that the tag is the only one of the three with a defined order, and the title is a human label. That is a reasonable convention, and it is also a convention that has to be learned rather than guessed.

It started as an internal consolidation, not a public launch

The project describes its own origin in a way that explains its shape. Before 2019 there were many internal design system and component library efforts inside the company, each organised around product-focused, decentralised rapid iteration. In 2019 the company established an open source collaboration committee, and the point of the project was to get teams working on similar technology products collaborating on one library instead of maintaining their own. The page is specific about how that was arranged: the collaboration scheme discussion, the component design work, and the API design work, source code included, are all open inside the company, under a policy described as equal, open, and strict regardless of a participant's role. It also describes the funnel, from trying the library in a personal project, to a first issue, to a first merge request, to code review, to core contributor. So the governance story is the real differentiator here, and it is the thing the numbers are attached to: over a thousand issues closed and five thousand code reviews in a year, feeding a weekly release.

Weekly release cadence across frameworks is the hard part

The stated advantage of the system is consistency across a multi-platform, multi-stack application, and the repository layout is the concrete form of that claim. A single design system expressed as three desktop libraries and five mobile ones has to keep the same component, the same token, and the same behaviour in step across all of them, and the weekly release is what makes that tractable: every framework's library gets a release on the same rhythm rather than drifting. The cost is visible in the tooling. There is a separate theme generator package with its own development, build, and watch scripts, which means tokens and themes are generated rather than hand-written and are part of what a release has to rebuild. There is also a service directory and an auto-release collection script, which is the sort of thing a project builds when publishing many packages consistently is itself the work. So the honest summary is that this is a distribution problem more than a design problem, and the weekly tag is the artefact of solving it.

Commit hooks run a formatter before anything is staged

The lint configuration is the quietest signal of how the project is run. There is a commit message configuration using the conventional format, a commitizen configuration pointing at the conventional changelog tool so contributors get a guided prompt rather than a manual template, and a lint-staged configuration that runs the linter with a fix flag and the formatter before staging, for the component file types, for the site's TypeScript files, and separately for markup files. A Node version file is committed, so the version every contributor formats against is fixed rather than whatever they happen to have. Husky wires the hooks up, and there is a separate configuration for the company build pipeline alongside the GitHub workflows. So an ordinary commit to a component goes through a fixer and a formatter before it is recorded, which is the mechanism behind the volume of small consistent changes that a weekly release across many packages depends on.

Editorial conclusion

Take TDesign if you are building an enterprise application and want one design language across a Vue, React, or mini program stack rather than three separate looks. Check three things first. The component library you want is a different package from this repository, and its release cadence is its own, so pin that package rather than this one. The version numbering on releases is date-shaped with a title that carries a different date again, so do not assume the tag and the release name mean the same thing. And the smallest supported stack is a real consideration, since a separate package exists for the older Vue 2 line and that package is not the same one as the modern Vue library.

Frequently asked questions

Official sources

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