vue-data-ui: sixty-odd charts and no charting library underneath

The install is one line and then a global registration

The installation section of the README is short, which is a good sign about the shape of the library:

npm i vue-data-ui

The README then shows declaring components globally in the main entry file, importing `createApp` and wiring the library in before mounting. That is a design decision with consequences: registering globally means any component in your tree can render a chart without a local import, which suits a dashboard application where many components draw data. It also means no per-file import statements to maintain, and no way to load only the two chart types you use unless you register selectively.

The package manifest confirms what you get at the artefact level. It is published as an ES module, the version in the manifest is 3.25.13, and the files array contains only `dist`, so what ships to npm is the built output rather than source. The export map exposes the main entry with type definitions, a separate `./utils` entry point with its own types, and a `./composables` entry point, which means the non-component helpers are available without pulling the whole component surface into your bundle.

What the component inventory actually contains

The README is essentially a catalogue, grouped by category, and reading it as a list is more informative than the marketing framing suggests. The charts group is by far the largest and includes the shapes you would expect to find in a storytelling toolkit: donut, gauge, heatmap, quadrant, radar, scatter, treemap, waffle, funnel, and a set of less common ones such as age pyramid, bump, chord, circle pack, dumbbell, galaxy, molecule, mood radar, onion, relation circle, ridgeline, tiremarks, word cloud and an xy canvas.

Below that sit mini charts: sparkline, sparkbar, sparkgauge, spark histogram, spark trend and spark stackbar, plus gizmo and bullet. These are the small multiples that sit inside a table row or a KPI tile, which is the clearest signal of the library's intended use. A general purpose charting library treats a sparkline as one chart type among many. Here it is a first class category.

There is also a tables group, which is the part most libraries skip. `VueUiTableHeatmap`, `VueUiTableSparkline`, `VueUiTable` and `VueUiCarouselTable` let a table cell carry its own mini visualisation, so you can show a metric and its recent trend in one row instead of building a separate chart panel. Rating components (`VueUiRating`, `VueUiSmiley`), map components (`VueUiGeo`, `VueUiWorld`), a three dimensional bar chart, and a utility group including `VueUiDashboard`, `VueUiKpi`, `VueUiDigits`, `VueUiSkeleton`, `VueUiAnnotator` and `VueUiCursor` complete the inventory.

Two details suggest how seriously the visual output is taken. There is a screenshot component listed among the topics, and the repository carries a `TestingArena/` directory and a `manual-testing/` directory alongside the Cypress suite, which is what you would expect from a project whose output is judged by eye.

The documentation site is the real interface

The README spends most of its length on links, and every one of them points at the same deployed documentation site. The component list, the props, the config objects and the examples live there rather than in the repository, and a second repository holds the documentation source.

This matters for evaluation. The repository tree contains no `docs/` directory holding the component reference; what it does contain is `llms.txt`, `AI_POLICY.md`, a `types/` directory, `ts-playground/`, and a set of maintenance scripts at the root: `add-dev-dep.cjs`, `del-dev-dep.cjs`, `check-types.cjs`, `copy-types.cjs`, `convert-json.cjs`, `cleanup.cjs`, `post-build.cjs` and `compress-world.mjs`. The last of those is a hint about how the world map data is handled. There is also `worldGeo.source.js`, which suggests the map component is fed from a source file rather than a runtime fetch.

So the honest description of this project is that the repository is the build, and the site is the manual. That is a common shape for a library whose differentiator is the look of its output, and it means you should budget time for reading the site rather than the README. The README does carry the badges that matter for a quick judgment: version, licence, whether type definitions are published, and download counts.

Rendering approach and the trade-off it implies

The library is written in Vue and publishes type definitions, and it does not delegate drawing to a separate charting engine. Its npm dependencies are modest, and the component names carry their own visualisation logic rather than wrapping a canvas library. The observable consequence is that the visual output is consistent across every component in a way that a mix of wrappers usually is not: the same spacing rules, the same colour handling, the same interaction language across a donut and a heatmap.

The trade-off runs the other way too. If you already have a general purpose charting library in your application, adopting this one means a second way to draw things, and migrating away from it later means rewriting every chart rather than swapping a configuration object. The category system also locks in its own vocabulary, so props are named for this library's concepts rather than following whatever convention your team already uses.

For accessibility and rendering details, the repository is not the place to look. There is no documentation in the tree about keyboard interaction, screen reader behaviour, or reduced motion handling. Those questions are answered by the documentation site or not at all, and they are worth asking directly if the dashboards you build are meant for other people rather than for an internal wall display.

Licence, release pace and who this suits

The licence is MIT, and the manifest names a single author. The repository is not archived and the last push was on 2026-09-26, with releases v3.25.11 on 2026-09-23, v3.25.12 on 2026-09-24 and v3.25.13 on 2026-09-25. Three patch releases inside three days is a fast cadence, and it is worth reading carefully: for a visual library that means someone is iterating on the appearance of components, and for you it means upgrade decisions arrive often enough to want a changelog habit rather than a big-bang version jump. The repository does keep a `CHANGELOG.md`.

The default branch is `master` rather than `main`, which is a small thing but tells you the project has been around long enough to predate that convention, and the version numbering has passed three. Twenty five minor versions for a component library is a lot of surface area, which cuts both ways: there is a component for the chart you had in mind, and there are a lot of decisions baked in that you did not make.

Who this suits, then. If you are building an internal analytics product, a client-facing report, or anything where the dashboard is the product rather than an internal tool, the shape of these components lines up with the job. If you are wiring a chart into an existing application that already draws its diagrams a particular way, or you need a chart type the list does not contain, you are going to fight it.

Editorial conclusion

vue-data-ui is a reasonable choice when the output you want is a designed, narrative dashboard rather than a generic set of axes, and when you already build in Vue 3 and would rather not configure a general purpose charting library. It is the wrong choice when you need arbitrary chart types it does not ship, when you need server side rendering of complex dashboards at scale, or when you want the renderers your team already knows. Start from the documentation site rather than the repository, because the site is where the component list, props and config objects live, and check the MIT licence terms against how you plan to ship the result.

Frequently asked questions

Official sources

1. graphieros/vue-data-ui on GitHub
2. License: MIT
3. Project website
4. README
5. Releases