wave-ui: a Vue component framework built by one maintainer

A component library that calls itself a framework

The package is described as a UI framework for Vue.js 3 and 2 with only the bright side, and the repository is titled Wave UI. The homepage is antoniandre.github.io/wave-ui, the licence is MIT, and the primary language is Vue.

The naming is worth a moment, because a framework usually means the thing that owns your application structure, while a component library means the pieces you assemble. What is on npm here is the latter: a package called wave-ui that exports a components directory, with a src/wave-ui/components/index.js entry point in the exports map. There is no application shell, no router and no store in the dependency list.

That is a good description of the design position the README takes. The phrase with only the bright side is the project's own framing of itself, and the keyword list in the manifest is explicit about the category: wave ui, ui framework, ui library, vue ui, vue3, vue framework and ui.

The scope of the library is what the documentation site covers, and the README does not enumerate the components. That is the first thing to check if you are evaluating it, because a component library is only as useful as the set you actually need.

Installation is one command, and Vue 2 lives behind a tag

The install section is two lines long. For Vue 3:

npm i wave-ui

And for the legacy Vue 2 build:

npm i wave-ui@legacy

The tag rather than a separate package name is a deliberate packaging choice, and it has a practical consequence. A single package name with two release channels means your lockfile records which one you installed, and a project on Vue 2 will keep pulling the legacy line while a project on Vue 3 pulls the current one. It also means the version numbers of the two lines are independent, so an upgrade in one does not drag the other along.

The browser support table is at the other extreme of the README's brevity: latest Chrome, latest Firefox, latest Safari, latest Opera and latest Edge are all marked as supported. There is no legacy browser row, and the repository carries a .browserslistrc file, which is where a bundler reads the target list from. The practical reading is that this is a modern-only library, and a project that has to support an older browser is going to have to check that before committing to it.

Dual bundles, declarations and a deliberate exports map

The package manifest is more interesting than a typical component library's, mostly because of the exports map.

The top-level fields point at an ES module build, a UMD build and the types separately: main is ./dist/wave-ui.esm.js, module is the same file, unpkg and jsdelivr both point at ./dist/wave-ui.umd.js, and types is ./dist/types/index.d.ts.

The exports map then repeats that structure with per-condition types, which is the part that matters for a modern toolchain:

  "exports": {
    ".": {
      "import": {
        "types": "./dist/types/index.d.ts",
        "default": "./dist/wave-ui.esm.js"
      },
      "require": {
        "types": "./dist/types/index.d.ts",
        "default": "./dist/wave-ui.umd.js"
      }
    },
    "./package.json": "./package.json",
    "./dist/*": "./dist/*",
    "./src/wave-ui": "./src/wave-ui/index.js",
    "./src/wave-ui/components": "./src/wave-ui/components/index.js",

Three things are happening there. The import and require conditions each carry their own types entry, so a TypeScript project resolves the declarations correctly whether it imports or requires. The package.json subpath is exported, which is the convention for tooling that reads package metadata. And the source paths are exported too, so a consumer can reach individual entry points rather than only the bundle root.

The manifest also declares type as module, and the files array ships dist and src/wave-ui, so the sources are in the published tarball as well as the build output.

Style files are marked as side effects, and that is deliberate

One field in the manifest is worth reading closely, because it says something about how the library is built:

  "sideEffects": [
    "*.css",
    "*.scss",
    "*.vue"
  ]

Declaring these as side effects tells a bundler not to drop them when it tree-shakes. That matters for a component library whose components carry their own styles, because a bundler that treats a .vue or .scss import as pure could remove the CSS and leave you with an unstyled component.

Getting this right is what lets a Vue application import a single component and not ship the whole library. The alternative, marking nothing as having side effects, would either bloat every bundle or produce broken styles, and the mistake is invisible until someone notices the styling has vanished in production.

The repository layout backs the same picture. There is a src directory for the library source, a docs directory, a public directory, an index.html at the root for the documentation site, a vite.config.js, a postcss.config.js for the styles, a biome.json for the formatter and linter configuration, and a tsconfig.json for the type build.

Vite builds the site, Biome checks the code, tsc builds the types

The scripts show a modern single-tool setup, and one distinction is worth noticing.

  "scripts": {
    "dev": "vite",
    "build": "vite build --base /wave-ui/",
    "build-types": "tsc -p ./tsconfig.json",
    "build-bundle": "BUNDLE=true vite build && npm run build-types",
    "preview": "vite preview --base /wave-ui/",
    "lint": "biome check .",
    "lint:fix": "biome check --apply .",
    "format": "biome format .",
    "format:fix": "biome format --write .",

The build and preview scripts both pass --base /wave-ui/, because the documentation site is served from a GitHub Pages project URL where the repository name is a path segment rather than a domain. Anything under that path has to be built with that base, which is the kind of detail that quietly breaks links when it is wrong.

The build-bundle script is the one that produces what npm gets, and it sets an environment variable, BUNDLE=true, before running the Vite build and then the type build. That separates the documentation build from the library build in the same Vite configuration, which is a reasonable way to keep one toolchain for both.

Lint and format are both Biome. There is a single tool doing both jobs, which keeps the configuration small, and the fix variants are the same commands with an apply or write flag. The repository also carries a pnpm-lock.yaml and an.editorconfig, and the fix variants make the tooling easy to run.

The README also carries a JavaScript Style Guide badge pointing at standardjs, indicating the code follows that style guide.

One maintainer, a sponsorship link and an invitation to fork

The README is short, and the parts about the people running it are the most informative.

The Donating section says you can buy the author a beer or become a sponsor, and adds that if you are using the library for profit business you should consider backing him, because it ensures that the project your products rely on keeps being actively maintained. The repository's funding field points at the same sponsor page.

That is the governance model stated plainly. This is one person's library, funded by sponsorship rather than by a company, and the author is telling you that commercial users should pay for the maintenance they depend on.

The Contributing section is equally direct. If you have any idea, feel free to open an issue to discuss a new feature, or fork Wave UI and submit your changes back to me. The second option is the interesting one for an evaluator, because forking is treated as a normal route rather than an escalation, which means the escape hatch is part of the design. If you need a change and the author is not going to make it, taking the library and maintaining your own copy is an expected outcome.

The Demo and Documentation section points at antoniandre.github.io/wave-ui, and the Release Notes live at antoniandre.github.io/wave-ui/release-notes, which is where the changelog for a project without GitHub releases is kept.

Version 4.2.5, no tagged releases, and a June 2026 push

The manifest version is 4.2.5 and the author is Antoni Andre. The repository is on the main branch and was last pushed on 2026-06-16.

The repository publishes no GitHub releases, and the npm badge in the README is the only version indicator on the front page. That is a deliberate arrangement for a project whose changelog lives on the documentation site rather than in the repository, but it has a cost for anyone automating an upgrade: there is no tag to compare, no release notes in the git history, and no way to see at a glance what changed between two npm versions without fetching the documentation site.

The package is on npm under the name wave-ui, with the download badge pointing at the npm registry, and the registry is where a project like this gets its release history even without GitHub releases.

The topics on the repository are framework, ui, ux, vue, vue3 and waveui, which is a fair summary of what the package is and of the fact that the Vue 3 line is the primary one, with the legacy tag serving the older major version.

The overall shape of the project is then easy to judge. A small, well-packaged component library with modern browser targets, dual bundles, correct tree-shaking metadata and a single maintainer who is candid about wanting sponsorship. Whether that is enough depends less on the code than on how much you need the library to still be there in three years.

Editorial conclusion

wave-ui fits a Vue team that wants a coherent set of components with a consistent look and would rather not build a design system in-house, and it is a reasonable choice for a Vue 2 codebase that needs to keep its existing components while moving on. It is the wrong choice if you need a vendor with a support contract behind it, since the project is one person's work with a donation link, and the wrong choice if your design system is already fixed and needs a component library that stays out of the way. Verify first which Vue major version you are on, because the Vue 2 build sits behind the legacy tag, and read the release notes on the documentation site before upgrading, since the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. antoniandre/wave-ui on GitHub
2. Issues
3. License: MIT
4. Project website
5. README