# arco-design-vue's only example registers the whole library

> arco-design-vue is a Vue component library of more than sixty components, built on a design system, with theming offered through two routes of which one is a vendor service. The page is short and its one code sample is the interesting part, because it installs everything and imports a single stylesheet.

**arco-design/arco-design-vue** — A Vue.js 3 UI Library based on Arco Design

- Repository: https://github.com/arco-design/arco-design-vue
- Website: https://arco.design/vue
- Stars: 3,106 · Forks: 604
- Language: TypeScript
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/arco-design-arco-design-vue

## The example installs everything, then imports one stylesheet

The page contains exactly one code sample, and it is a full registration rather than a per-component import.

```typescript
import { createApp } from 'vue'
import ArcoVue from '@arco-design/web-vue';
import App from './App.vue';
import '@arco-design/web-vue/dist/arco.css';

const app = createApp(App);
app.use(ArcoVue);
app.mount('#app');
```

Four lines of import, then the plugin installed on the application instance, then a mount. Two things are worth reading out of that.

The first is that the stylesheet is a single file imported for its side effect, from a distribution path rather than from a styles entry point. That is the older convention, and it means the styling is all-or-nothing.

The second is that the library is registered wholesale. For a component library whose headline is more than sixty components, the documented starting point is the version that ships all of them. Nothing on the page mentions importing individual components, which is the technique a bundle-conscious application would reach for instead.

So the page's most consequential line is also its least remarkable: the default path is the whole library.

## Sixty components, and theming offered two ways with one marked recommended

The features section is three items, and the middle one is the interesting one.

The first is the component count: more than sixty crafted components usable out of the box. The third is that every component is written in TypeScript, which the page describes as making the library type friendly.

The middle one is theming. The mechanism is a set of theme tokens that can be customised to build your own theme, and the page offers two ways to do it. The first is building the tokens through the stylesheet preprocessor. The second is the vendor's own design platform, and that option is marked as recommended with an exclamation mark.

That recommendation is a design decision with an operational consequence. One of the two documented theming routes is a hosted tool outside your repository and outside your build, so a team that themes through it has a design system whose source of truth is a web application. The other route keeps the tokens in your own stylesheets.

Nothing on the page says what happens to a theme authored in one route when you move to the other, so the choice is worth making deliberately rather than by following the recommendation.

## Two releases three minutes apart, after a gap of about two years

The three most recent releases are numbered in the 2.5x line, and their timestamps tell an unusual story.

The two newest, 2.57.0 and 2.58.0, were both published on the same day in April 2026, three minutes apart. The one before them, 2.56.0, dates from July 2024.

So the pattern is a long gap followed by two adjacent versions in the same three-minute window. That is what a burst looks like: the accumulated work since the previous release is cut into two increments and pushed almost simultaneously, presumably to separate a fix from a feature without waiting for the next calendar slot.

The branch itself was last pushed to in June 2026, two months after those releases, so development is continuing between them.

For a consumer, the practical question is which version to pin, and the page gives no guidance on that. It also does not mention a changelog, a support policy, or a version compatibility matrix for Vue itself, so the relationship between a 2.5x release and a given Vue version has to be established elsewhere.

## The repository is a private monorepo with its own toolchain versions

The repository is not the package. Its root manifest is named as a monorepo, marked private, and declares a workspace over a packages directory, while the package you install is published under a scoped name with a web-vue suffix.

That means the source of truth for a developer is a set of packages inside the workspace, and the root manifest exists to orchestrate them. Its scripts are all filters: start the documentation site, build the library, build the site, generate the library's documentation, run its tests, run its screenshot tests, and start a separate storybook package.

Two of those deserve attention. One initialisation script first builds three internal packages, then runs an install, and then runs an initialisation inside the library package, which means the second install is part of bootstrapping rather than something you did. And a clean script recursively removes the output and dependency directories of every package at once, so it is not a targeted operation.

There is also a postinstall that installs the git hooks. So cloning the repository is enough to get the commit conventions enforced, which is the polite default and also means the hooks are running before you have agreed to them.

## Two linters for two languages, both several majors behind

The development dependency list is a timestamp in disguise, and it dates the project precisely.

The JavaScript and TypeScript side uses the linter at version 7, with a matching plugin for TypeScript at version 4, a Vue plugin at version 7, an import plugin, the Airbnb base config, and a prettier compatibility config. Version 7 of that linter predates the flat configuration file format, which is why the repository root carries both an eslintrc file and an ignore file rather than a single configuration.

The stylesheet side is the same story: the CSS linter at version 13 with the standard config, a prettier compatibility config, and two ordering configurations, one of them a rational-order preset. That a component library enforces declaration order in its CSS is a sign of how much of the visual system is hand-tuned.

The formatter is on version 2 of its line, and the commit message linter is on a much older major still, paired with the conventional-commit preset.

Meanwhile the root manifest pins the package manager to a specific modern release. So the install toolchain is current and the lint and commit toolchain is several years behind, which is the shape of a project that upgrades what it needs to build and leaves what it only needs to check.

## Screenshot tests, a storybook package, and generated documentation

Three of the root scripts exist to check that the library looks and reads correctly, and they are the clearest statement of what the project considers its quality bar.

A screenshot test script runs inside the library package. For a component library, a screenshot test renders each component and compares the result, which catches the regressions that a type check cannot: a broken layout, a missing icon, a spacing change from a token edit.

A separate storybook script targets its own package rather than the library, so the component gallery is a distinct application inside the workspace with its own dependency tree.

A documentation generation script also runs inside the library, which suggests component metadata is extracted rather than hand-written, so that the props table in the documentation cannot drift from the types.

None of these three is a unit test of behaviour in the sense most people mean by that phrase, and the only test script in the root manifest is the one that forwards to the library's own suite. So the visible investment is in appearance, gallery and documentation rather than in logic tests.

## The ecosystem around the library is five more vendor products

The page's ecosystem section is a table of five projects, and it is where the design system stops being a library and becomes a product line.

The first is a React component library built on the same design system, which is how a team keeps one visual language across two frameworks. The second is the theme platform already mentioned, for creating and managing themes. The third is a marketplace for customised materials, described as providing large quantities of high quality customised assets. The fourth is an icon management service. The fifth is a scaffolding solution for building applications from scratch, which is the commercial version of the quick start.

Then the useful links: the documentation site, a dark mode guide, the theme customisation page, a Figma component library, and a community list of related resources.

Two observations. The React library and the Vue library sharing one design system means the tokens, the icon set and the visual decisions live upstream of both, so a divergence between them is a question about the shared source rather than about either implementation. And four of the five ecosystem entries are services rather than code, which is the commercial shape of a design system: the components are the free part and the tooling around them is the product.

## Two readmes, two contributing guides, and a typo in the last line

The repository is bilingual in a way that goes past the readme.

There is an English readme and a Simplified Chinese one, linked from a language switcher near the top. There is also an English contributing guide and a Simplified Chinese one, which is more work than most component libraries do, because contributions are the part that needs translating most often.

The closing lines are where the care lapses. The licence section reads as this project being licensed under the MIT licence, with the first word misspelled. Above it is a contributors graph link and a line thanking everyone who has already contributed, which is standard.

Everything else about the root is tooling: an editor configuration, the linter configuration and its ignore file, an attributes file for line endings, a gitignore, the hooks directory, an npm registry configuration file, a pinned node version file, a prettier configuration written in JavaScript, and an editor directory.

The pinned node version and the registry configuration are the two that matter to a contributor and the two that the page never mentions, which is the gap a new contributor fills by reading the repository rather than the documentation.

## Conclusion

arco-design-vue suits a team already invested in that design system, or one that wants a large component set in Vue with types rather than hand-rolled wrappers. Three things to check before you commit. Read the registration example, because it installs the entire library and one stylesheet, and decide whether that is acceptable for your bundle. Decide where theming lives, since one of the two documented routes is a vendor-run design platform rather than something in your build. And check the release cadence, because two of the three recent versions shipped minutes apart after a gap of about two years, so the project's activity arrives in bursts rather than steadily.

## FAQ

### What is arco-design-vue?

It is a Vue 3 component library built on the Arco Design system, with more than sixty components, theme tokens that can be customised, and every component written in TypeScript. It is MIT licensed and published to the registry under a scoped package name ending in web-vue.

### How do I install arco-design-vue?

With one package and three package manager commands, shown for npm, yarn and pnpm. The page's only code sample then installs the library as a plugin on the application instance, imports the component file it renders, imports the library's stylesheet as a single global file, and mounts.

### How do I theme arco-design-vue?

The page gives two routes for customising the theme tokens: building them through the stylesheet preprocessor, or using the vendor's own design platform, which the page marks as recommended. The first keeps the tokens in your own build; the second keeps them in a hosted tool.

### What else does the Arco ecosystem offer?

Five linked projects: a React component library on the same design system, a theme creation and management platform, a marketplace for customised materials, an icon management service, and a commercial scaffolding solution. The page also links a dark mode guide, the theme documentation, a Figma component library and a community resource list.

### What does the arco-design-vue repository contain?

A private monorepo root over a packages workspace, holding the library, the documentation site and the tooling packages. Root scripts build the library, generate its documentation, run its tests and its screenshot tests, and start a separate storybook package. Git hooks and a commit message convention are configured at the root, and there are parallel English and Chinese contributing guides.

### Which tool versions does the arco-design-vue monorepo pin?

The root manifest pins its package manager to a specific modern release while the checking tools stay on older majors: the JavaScript linter on the 7 line with a matching TypeScript plugin at 4, the CSS linter on the 13 line with ordering configurations, and the commit message linter on a much older line, alongside a formatter on its 2 line.

## Sources

- [arco-design/arco-design-vue on GitHub](https://github.com/arco-design/arco-design-vue)
- [License: MIT](https://github.com/arco-design/arco-design-vue/blob/main/LICENSE)
- [Project website](https://arco.design/vue)
- [README](https://github.com/arco-design/arco-design-vue/blob/main/README.md)
- [Releases](https://github.com/arco-design/arco-design-vue/releases)

---

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