Vuestic UI: a Vue 3 component library with a business behind it

Who builds the library and who designed it

Vuestic UI is a Vue 3 component library. The README credits two distinct parties, which is unusual enough to be worth separating. It was developed by Epicmax and designed by Vasili Savitski. That split matters if you are choosing a library: the design language comes from a named designer rather than accumulating from whatever contributors happened to send, and the maintenance comes from a company whose business includes selling development services.

Epicmax is explicit about the commercial relationship. The README has a section inviting hiring enquiries, noting that Epicmax created and backed Vuestic UI and has supported it through all the years, and offering consultation or web development work. There is a separate section for premium support and consulting through Epicmax as the official development partner, and a section describing Vuestic Admin as a real-world application built on the library. The library itself is MIT licensed and the README states it is free and open to contributions.

The repository metadata backs that up with numbers: roughly 3,700 stars and 350 forks, a homepage at vuestic.dev, and a topic list that includes accessibility, semantic, typescript, ui-components, ui-kit, vue3 and vuestic. Accessibility and semantic appear as topics in their own right, not as a line in a changelog, which tells you where the project wants to be judged.

One command scaffolds a project, not just a dependency

The quick start section of the README is a single command.

npm create vuestic@latest

What that command starts is worth reading carefully, because it is broader than installing a package. The README says it quickly scaffolds a new Vite or Nuxt project with Vuestic, or with Vuestic Admin. So the same entry point offers a bare component library project and a full admin template, and it offers two build targets, Vite and Nuxt.

That distinction has practical consequences. A Vite project gets the library wired into a standard client-side build. A Nuxt project gets the Nuxt module, which is published separately as @vuestic/nuxt from a directory in this repository. The README badges show the published packages alongside the core: @vuestic/nuxt, @vuestic/tailwind and @vuestic/ag-grid-theme, the last of which lives in an ag-grid-theme directory under the extensions folder.

For most people the fastest route is the scaffolding command rather than a manual install, because the wiring for a library with this many optional integration packages is exactly the part that is tedious to reproduce by hand.

The repository root is a monorepo wrapper, not the library

The root package.json is named vuestic-ui-wrapper, marked private, and versioned at 1.0.0. That is the first thing to understand about the layout: the file you see at the root of the repository is a wrapper that exists to drive workspaces, not the package you install from npm. The actual library lives under the packages directory, and the README links straight to packages/ui/package.json for the published version number.

The wrapper declares lerna for versioning across packages and syncpack to keep dependency versions consistent between them. It also brings in tsx for running TypeScript directly, yorkie for git hooks, and a pinned @types/node. Alongside those sit a set of scripts that read like a map of the whole project.

The scripts fall into recognisable groups. There are Storybook scripts for serving and building it. There are unit test and bundler test scripts, and the bundler test script is interesting because it builds the Nuxt package first before running the bundler tests, which means the Nuxt integration is verified as part of the same pipeline rather than separately. There are documentation scripts for serving and building the docs workspace, plus generation scripts for a docs page and for a single component. There are lint and lint:style scripts, and build:types for emitting declarations. There is a release script that delegates to a deploy workspace.

The pattern is a conventional Lerna and Yarn workspaces monorepo: lerna.json and yarn.lock at the root, a yarnrc.yml, an nvmrc pinning the Node version, a .editorconfig, a stylelintrc.js and a cypress.json for end-to-end tests. CircleCI configuration in the .circleci directory and a ws-context file complete the picture of a project with real release automation rather than ad hoc publishing.

Four bundler targets, maintained as sandboxes

The most instructive line in the root package.json is the sandbox group. There are four scripts, and each one runs a dev server for a different target.

"sandbox:vite": "yarn workspace sandbox dev:vite",
"sandbox:nuxt": "yarn workspace sandbox dev:nuxt",
"sandbox:vue-cli": "yarn workspace sandbox dev:vue-cli",
"sandbox:web-components": "yarn workspace sandbox dev:web-components",

Read that as a statement of supported targets rather than as four debug helpers. Vite is the modern default. Nuxt covers server-rendered applications through the @vuestic/nuxt module. Vue CLI is the older Vue toolchain, kept alive here for projects that have not migrated. Web components covers the custom-element build, which matters if you intend to consume the library outside a Vue application.

Four targets means four ways for the same component to break, and it means the maintainers accept that cost deliberately. It also gives you a diagnostic tool: if a component misbehaves in your build but renders correctly in one of these sandboxes, the problem is in your integration rather than in the library.

Reading the gap between the last release and the last commit

The repository metadata shows a last push in early May 2026, and the newest tagged release is v1.10.3, published in October 2024. That gap is about nineteen months, and it is the single most useful fact on the repository page for anyone planning a dependency.

Two readings are possible and the evidence does not settle between them. One is that work continues on the develop branch, which is the branch named throughout the README links, and that release tags are cut in batches. The other is that publishing has slowed relative to development. The v1.10.3 release notes themselves are consistent with an active project: they fix a button dropdown teleport problem when split is used, fix a non-working errorCount prop on the form field, stop applying extra styles in non-headless mode, bump webpack through Dependabot, and add a decimal character option to the input mask.

That last group of changes tells you two things about how the library is maintained. Dependabot is wired up, so dependency updates arrive as automated pull requests rather than as manual chores. And several fixes are narrow and specific, which is what you see in a project with many users filing precise reports about individual components.

Practically, pin your dependency to an exact version rather than a floating range, and read the release notes for the version you pin. A library whose newest tag is nineteen months old is not abandoned, given commits in May 2026, but it is one where the tag list is a poor guide to what is in the develop branch.

Where to look when a component misbehaves

The README points documentation, guides, examples and tutorials at ui.vuestic.dev, and the main site is vuestic.dev. Community discussion happens on a Discord server, and there is a contributing guide on the docs site alongside a link to open issues.

There is also a visual regression setup that is easy to miss. The README credits Chromatic as the provider of a visual testing platform used to review UI changes and prevent visual regressions, and it credits BrowserStack for the infrastructure that allows testing across browsers, with a Netlify badge for deployments. For a library whose entire job is how things look, that tooling is the difference between a visual change being reviewed and a visual change slipping through a pull request description.

When something breaks, the order to work in follows from the tooling. Reproduce it in the closest sandbox first, since that isolates your build from the library. Then check whether a fix or an issue already exists. Then, if you have a patch, the repository has lint, lint:style, test:unit, test:bundlers and Storybook build scripts, so a pull request that keeps those green is a pull request that can be merged without further work from you.

Editorial conclusion

The concrete next step is to run npm create vuestic@latest and compare the generated package.json against the sandbox scripts already in this repository: sandbox:vite, sandbox:nuxt, sandbox:vue-cli and sandbox:web-components exist precisely so you can see which bundler configuration the maintainers test against before you pick one.

Frequently asked questions

Official sources

1. epicmaxco/vuestic-ui on GitHub
2. License: MIT
3. Project website
4. README
5. Releases