Vant ships one component set for mobile web, split across two Vue version lines

The install tag routes you to a different line, not a different version

The install block splits on the Vue major version, and the tag does the routing rather than a version number.

# install latest Vant for Vue 3 project
npm i vant

# install Vant 2 for Vue 2 project
npm i vant@latest-v2

Yarn, pnpm and Bun all take the same package name through their own add subcommand.

For a reader, the tag is a compatibility decision disguised as a version number. Two apps can both say they depend on Vant and share nothing but a name. Your lockfile is the only place that records which Vant 2 build you actually ran, so keep it. The Quickstart also imports its stylesheet from `vant/lib/index.css`, and the README shows no separate path for the Vue 2 line.

The Quickstart names one component and one stylesheet for the whole library

Look at what the Quickstart actually registers.

import { createApp } from 'vue';
// 1. Import the components you need
import { Button } from 'vant';
// 2. Import the components style
import 'vant/lib/index.css';

const app = createApp();

// 3. Register the components you need
app.use(Button);

`import { Button } from 'vant';` is a named import, so a bundler can drop the components you never reference, and the feature list claims tree shaking support on that basis. Style is different. `import 'vant/lib/index.css';` is a single path, and the README shows no second stylesheet path per component, so there is nothing here for a bundler to shake at the CSS level.

What that costs a reader is a dev build carrying every Vant rule regardless of which components the page uses. Whether unused rules disappear from a production build depends on your own configuration, and the project ships no default for it here. If you are auditing bundle size, measure the CSS separately from the JavaScript, because the tree shaking claim covers one of the two and says nothing about the other.

Browser floors split along the Vue line, and there is no polyfill story

Browser support is stated once per version line. Vant 2 supports modern browsers and Android >= 4.0, iOS >= 8.0. Vant 3 and 4 support modern browsers and Chrome >= 51, iOS >= 10.0, which the README notes is the same floor as Vue 3 itself.

That is a fork in the road rather than a compatibility layer. If your traffic analysis still shows devices below iOS 10, the only Vant line that reaches them is the Vue 2 line, and choosing it means choosing Vue 2. No 4.x build keeps the older floor, so there is no configuration that gives you both. Teams that inherit an existing Vue 2 app and a traffic report full of old Android devices should settle that trade before picking a component library at all.

The repository refuses npm and pins pnpm 10.33.2 twice

The root package is marked `private`, pins `[email protected]` under `packageManager`, and asks for `>= 10.34.7` under `engines`. Every script delegates into the workspace member: dev, test, test:watch, test:update, test:coverage and build all run `pnpm --dir ./packages/vant` first, prepare runs `rs hooks`, and lint runs `rs lint`. The top level carries `pnpm-workspace.yaml`, `pnpm-lock.yaml`, `rstack.config.ts` and a `.rstack/` directory, with `@vant/cli` held at `workspace:*` and `rstack` at `^0.8.0`.

A contributor therefore cannot reproduce this checkout with npm, and the `overrides` entry pinning esbuild to `^0.28.2` means the bundler under the test suite is not yours to bump when something breaks locally. The last push is dated 2026-11-02 and the 4.x line shipped v4.10.2 on 2026-08-31 after v4.10.0 on 2026-06-28, so the code moves often even though the tooling chain is deliberately narrow.

Accessibility is listed with a qualifier and nothing behind it

The feature list carries one accessibility entry and it ends with a parenthetical: still improving. That parenthetical is the entire extent of what the README says about it. No component is named as carrying ARIA roles. No focus order is described. Nothing is documented about screen reader behavior for any specific component, and the 1KB average and 90%+ unit test coverage claims elsewhere in the list say nothing about either.

So if accessibility sits in your acceptance criteria, the library hands you no checklist to test against. You open each component you intend to use and verify it yourself, and the project has not published those results. Any statement that a given component is accessible becomes a claim you make and defend, not one the repository makes for you. Budget for that verification work rather than treating the feature list entry as coverage.

Every target that is not a Vue web page is a different repository

The README draws a line between official and community projects, and everything outside the Vue web target lives on the other side of it. The official table lists vant-weapp as a WeChat MiniProgram UI. The community table lists Taroify as the Taro version of Vant, @antmjs/vantui as mobile UI components supporting Taro and React, and react-vant as React mobile components based on Vant. Three separate maintainers and three separate version lines.

A Taro or React team cannot install `vant` and expect coverage of their target. These ports are separate repositories with their own release cycles, and nothing in this repository commits to component parity between Vant 4.x and any of them. If you share a design system across a Vue web app and a Taro app, assume the two sets diverge and verify the components you actually use against the port you actually ship.

Desktop development needs vant-touch-emulator, with no setup steps given

Touch input is treated as an environment you might not have. The official ecosystem table lists vant-touch-emulator with the description of using Vant in desktop browsers. That entry exists because a component built around touch events does not behave the same way when you open the page in a desktop browser with a mouse, and the project's answer is a separate package rather than a flag on the components themselves.

Local development on a laptop is therefore not a faithful preview of a phone. When swipe gestures or overlay dismissal misbehave in a desktop browser, the likely reason is missing touch emulation, not your own CSS. What the README does not give you is a list of which components depend on the emulator, or any setup instructions for it, so you will be reading that package's own documentation to close the gap.

Dark mode, i18n, theming and SSR are four claims with four different depths

Four separate entries in the feature list, each documented to a different depth. Dark Mode is listed with no indication of how many of the 80 or more components carry dark styles. i18n is the only one with a number attached: built-in 30+ languages. Custom Theme is listed with no config key and no file path in the README. SSR is listed with no notes at all.

The tool you would reach for when tuning a palette, vant-theme, sits in the community ecosystem table rather than the official one, and nothing here says which Vant release it tracks. That matters for a reader deciding what to build on: a palette that looks correct in the online preview is not evidence about the values that shipped. Confirm the theme variables against the documentation site before you commit a color scheme, and check dark mode per component rather than assuming the entry covers all of them.

Editorial conclusion

Pick Vant when the product is a Vue mobile web page and you want components with a 1KB average gzipped size and no third party dependencies. Do not pick it for a Taro, React or mini program build, since those run on separate repositories with their own maintainers. Before committing, install both tags on a scratch page and check the three components your design actually uses against a screen reader, because accessibility is still marked as improving and no component list is published.

Frequently asked questions

Official sources

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