una-ui: an atomic UI framework for Nuxt built on UnoCSS

The styling engine is UnoCSS, not a component stylesheet

Una UI describes itself as the Atomic UI framework for Nuxt, powered by the Unocss engine. The word atomic is the important one, and the topic list makes the stack explicit: nuxt, tailwindcss, unocss, unjs, vite, vue and typescript.

That combination places it in a specific family. Rather than shipping a set of components with pre-written CSS classes and a theme file, the framework leans on a utility-first engine to generate the styles, and the package keywords describe the shape of the output: design-system, tailwindcss, unocss, components, ui-library, theming, postcss and design.

The audience is a Nuxt team that has already chosen, or is about to choose, a utility CSS approach and wants a component layer that fits inside it rather than fighting it. The theming keyword is the clue to how the design system is expressed, through tokens the engine understands rather than through a bespoke stylesheet.

The homepage is listed as v1.unaui.com, and the README points the documentation at unaui.com. The distinction matters, because the two addresses belong to different generations of the project, and the version numbering in the npm tags suggests that the v1 line is the current generation.

So the value proposition is a component layer that is native to the UnoCSS setup, not a design system that has to be taught a new styling language. Whether that is worth it depends entirely on how comfortable the team is with utility CSS as the base layer.

Two packages, two branches, and a warning before anything else

The first thing in the README is a warning: this project is heavily working in progress. That sets the expectation for everything else, and the release table then shows how the project handles the gap between a stable line and a moving one.

There are two rows. Main, labelled Edge, publishes the @una-ui/preset-edge package, and Release publishes @una-ui/preset. The two are built by different workflows, ci.yml for the main branch and release.yml for the release branch, and each row carries its own version badge and its own download counter.

This is a common pattern in the JavaScript ecosystem and a useful one, because it lets a consumer choose how much churn they accept. The release package is the one to put in a production application. The edge package is where the next release line is rehearsed, and a team that wants to see the new API before it is published can pin the edge package instead.

The tags make the state of the 1.0 line explicit: v1.0.0-alpha.27 from 2026-09-06, v1.0.0-alpha.26 from 2026-08-31, and before that v0.67.10 from 2026-08-24. Alphas numbered in the twenties mean the API is still moving, and a project that labels itself work in progress while shipping that many alpha tags is telling you to expect breakage between minor versions.

The repository root package.json still reads version 0.67.10, so the number in the source and the number on the registry are not the same thing. That is normal for a monorepo whose root is private, but it is another reason to read the npm tag rather than the repository file when you check what you are installing.

A pnpm workspace with a preset, a Nuxt module and a docs package

The repository is a monorepo, and the shape of the scripts tells you what the packages are.

The root package.json is named @una-ui/monorepo and is marked private, with the description The Atomic UI Framework, the author Phojie Rengel, and the type module. Three scripts filter directly to packages: preset runs against @una-ui/preset, nuxt runs against @una-ui/nuxt and docs runs against @una-ui/docs. Those three names are the shape of the project: the UnoCSS preset, the Nuxt integration, and the documentation site.

The build script is worth reading because it shows how the packages are produced. It removes the dist directory from every package, copies files with a script under scripts/, and then runs the build in each package under packages/ filtered to that directory. The stub script does the same for development, and the dev script runs stub first and then the dev task in every package, so a developer works against locally built packages rather than the published ones.

The rest of the tree supports that workflow. There is a config/ directory, a docs/ directory, a test/ directory, a scripts/ directory, an uno.config.ts at the root for the UnoCSS configuration, a tsconfig.json and an eslint.config.js. There is also a pnpm-workspace.yaml and a pnpm-lock.yaml, and a renovate.json for automated dependency updates.

A detail that says something about how the project is built for tooling as much as for people: the tree contains a skills-lock.json along with .agents/ and .claude/ directories, which suggests the project ships agent-facing instructions alongside its human documentation.

Node 20 and pnpm are enforced, not suggested

The toolchain constraints in the root package.json are strict, and one of them is enforced by a script rather than by documentation.

The engines field declares node at 20 or newer. The package manager field pins pnpm at 10.29.3, and the preinstall script runs npx only-allow pnpm, which fails the install if you reach for npm or yarn. That is a deliberate choice for a monorepo, where a single lockfile and a single workspace layout are what make the filtered builds work.

The consequence for a consumer is worth being clear about. If you add Una UI to a Nuxt application that is already on npm or yarn, the preinstall guard in this repository does not affect you, because you are consuming a published package rather than installing the monorepo. If you clone the repository to contribute, you need pnpm, and the reset script shows how the maintainers deal with a broken state: it prunes the pnpm store, removes the docs build and node_modules directories and the lockfile, and reinstalls.

The other scripts cover the quality gates. The test script runs vitest, typecheck runs vue-tsc with no emit, and lint runs eslint over the repository, with a lint:fix variant. The changelog script runs conventional-changelog with the angular preset and writes into CHANGELOG.md, and the release script runs the tests, then bumpp with a changelog generation, then publishes every package, then runs a release script from scripts/.

That release pipeline is worth noting for a project at alpha: the publishing is automated, the version bump is automated, and the changelog is generated from commit messages. The churn is in the API, not in the process.

The docs, the starter and the playground are separate surfaces

The README's references table lists four things, and the distinction between them is the fastest way to understand the project.

The documentation is at unaui.com. The starter kit is a separate repository, github.com/una-ui/starter, with a live instance at starter.unaui.com. The playground is at play.unaui.com. And the homepage of the repository itself is v1.unaui.com.

A starter kit as its own repository is a deliberate structure. It means the quick start a newcomer copies is versioned separately from the framework, so the example project can move to a new API before the framework's own release line does. The live starter then doubles as a check on whether the current release actually works end to end, and the playground as a place to try components without a project at all.

The docs are built from the repository, with a docs package in the workspace and a deploy script that runs the build and then the docs build, and there is a vercel.json at the root, which is how the sites are hosted.

So an evaluation has a cheap form. Open the starter repository, run it against the release package, and see whether the components behave the way the documentation claims. That is a better test than reading the component list, and it costs one clone.

Where the framework is the wrong choice

There is a real case against adopting Una UI right now, and it is not the quality of the components.

The first is the version line. A 1.0.0-alpha.27 tag means the public API of the current generation is still settling. The README says the project is heavily work in progress, and the presence of an edge package built from the main branch is the project telling you that some of what you use will change. For a team whose product surface is stable, a component layer that changes its API between alpha versions is a maintenance line item that has to be budgeted for.

The second is the fit. If your team has not settled on UnoCSS or a utility first approach, this framework adds a component layer on top of a decision you have not made. A conventional component library with its own styles works with any build setup and needs no engine configuration, and for a team without a styling strategy that is a smaller decision.

The third is the age of the 0.x line against a Nuxt generation. The v0.67.10 tag and the alpha v1 line sit in the same repository with different semantics, and the documentation addresses unaui.com while the homepage points at v1.unaui.com, so a reader can end up on documentation for a different generation than the package they installed.

None of this makes the project bad. It makes it early, and the sensible engagement is the starter repository and the release package rather than the edge package.

MIT terms, active commits and a published alpha cadence

The licence is MIT, with the LICENSE file at the root of the repository and the README stating MIT License, copyright 2023 Phojie. The package metadata carries the same licence value, the same author and the same year. That is a permissive grant with no copyleft obligation, which is the easy case for a company shipping a product built on it.

Maintenance is active. The last push was on 2026-10-20 and the repository is not archived, and the release cadence in the v1 line is two alpha tags in the second half of August and September 2026, with the 0.x line tagging v0.67.10 in between. The CI status for both the main and the release branch is surfaced in the README table, which means the two lines are built and checked independently.

The upgrade cost for a consumer is the thing to judge. If you are on the release package, an upgrade is a version bump and a read of the changelog, and the changelog is generated from commit messages, so it is usually informative. If you are on the edge package, an upgrade is an API migration, and the alpha numbering is the warning label.

There is a sponsorship section and a GitHub Sponsors link in the project metadata, which for a single-maintainer framework with an open issue tracker is a reasonable signal about where support obligations sit. The concrete takeaway is that the release package from the release branch is the version to build on, and the edge package is for reading the code before it is published.

Editorial conclusion

una-ui fits a Nuxt team that has already committed to a utility CSS approach and wants components that live inside it, and it does not fit a team still choosing a styling strategy or one that needs a frozen component API. Before adopting it, clone the starter repository and run it against the release package rather than the edge package, and check the tag you install, since the current 1.0 line is still at alpha.

Frequently asked questions

Official sources

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