Onu UI and the current state of an opinionated UnoCSS component library

A component library that refuses to ship a stylesheet

Onu UI describes itself as an opinionated and lightweight UnoCSS ui library, and the first item in its feature list sets the tone: pure atomic css, with no need to introduce additional css files.

That is a real architectural position rather than a slogan. Most component libraries ship CSS alongside their components, which means a stylesheet, a class naming scheme, and a decision about specificity and load order. An atomic CSS approach generates the classes you actually use from the markup, so there is no separate file to load and no runtime cost for rules nobody referenced.

The second feature is simple and efficient, described as rendering UI with the least amount of code. The third is the one that matters for anyone who has used atomic CSS before: expand easily, because atomic css allows you to freely combine the styles you want. In practice that means the component gives you a structure and the styling hooks, and you adjust it with utility classes in the template rather than by overriding a theme file.

The project is TypeScript, MIT licensed, and the credit list names UnoCSS itself, daisyui and @nuxt/ui, which is a good description of the lineage: a design system borrowed from existing work and reimplemented as Vue components on top of UnoCSS.

The homepage is onu.zyyv.dev, the documentation lives at onu.zyob.top, and the repository top level shows the full shape of a modern frontend library: a pnpm workspace with a packages directory, an examples directory with a Vite preset only example and a Vite plus Vue example, a docs site, a test directory, and a vitest configuration.

The theme is generated for human vision, not by hand

The dynamic theme feature is the most distinctive claim in the list. The theme is generated with Magicolor and the description says it conforms to human visual perception.

That is a different starting point from the usual design token workflow. The common approach is to hand-pick a palette, check it for contrast, and adjust. A generator that derives colours from perceptual rules produces a palette that behaves consistently across hues and lightness steps, which matters when a library exposes dozens of components that each need their own shade.

Toggle theme is the second half of the story. The library automatically adapts to dark or light mode, so a consumer does not write a media query or a class toggle for every component.

Together these two features are the reason to call the library opinionated. The colour decisions are made for you, consistently, and the dark mode handling is not something you have to wire up. The cost is the obvious one: if the generated palette does not match a brand, you are overriding a system rather than configuring it, and the documentation is where you would find out how much control the theme actually exposes.

The UI design feature, described as neat and beautiful crafted UI components, is the part of the list that carries no information, which is worth noting. It tells you the components exist and that the author considers them well made, and nothing about what they do.

The resolver is the part that decides your bundle

On demand is described as providing a resolver to automatically import only used components. This is the mechanism that makes the whole approach work.

A resolver in UnoCSS is what inspects your source and decides which utility rules and which component imports are needed. When it is configured to pick up only the components you use, an application that uses three components ends up shipping three components rather than the whole library. In a project that uses a component library casually, that difference is often the difference between a few kilobytes and a few hundred.

The other listed capability here is Iconify Icons, described as use any icon from the library you love. Combined with the atomic approach, icons are another thing you reference by name in a template and the tooling resolves. The monorepo's own dev dependencies show the icon sets used during development, with iconify packages for carbon, fluent-emoji, logos and ri, which tells you those four are the ones exercised by the project's own examples and tests.

TypeScript support is listed as support for TypeScript, type checked and type inference. In a component library that is not a small claim, because the difference between a component that accepts a loosely typed props object and one whose props are inferred in the template is the difference between editor autocomplete being useful and being absent. The repository supports that with typecheck running tsc --noEmit and a volar:helper script that generates the editor type helper files.

A pnpm monorepo with two examples and one package to copy

The root package.json is a private monorepo manifest named @onu-ui/monorepo, and it documents the whole development workflow in one place:

  "packageManager": "[email protected]",
  "license": "MIT",
  "engines": {
    "node": ">=22.13.0"
  },

The scripts show that the project builds as a set of packages rather than a single one, and that the examples are separate runnable apps:

    "build": "pnpm clean && pnpm -r --filter='./packages/*' run build",
    "play": "pnpm -C examples/vite-onu-preset-only run dev",
    "example-vue": "pnpm -C examples/vite-onu-vue run dev",
    "test": "vitest",
    "typecheck": "tsc --noEmit"

The two examples are the interesting part for an adopter, because they answer the question a component library README usually leaves open. The first is the preset only example, the vite-onu-preset-only directory, which is the minimal setup where you use the UnoCSS preset and its theme without the Vue component layer. The second, vite-onu-vue, is the full arrangement with the Vue components in place. The dev-preset and dev-vue scripts run each of them alongside the relevant package's own dev server, so you can watch the library and the example side by side.

The rest of the toolchain is familiar and modern. Linting is eslint with the antfu config, tests run on vitest with an update flag for snapshots, formatting is handled through simple-git-hooks installed on postinstall, and the release script is bumpp. The presence of a docs directory with its own build and preview scripts, plus a netlify.toml, is what makes the documentation site at onu.zyob.top possible.

Two examples say more about intended usage than the feature list

Because the repository ships two example applications, you can see two distinct ways of using the library rather than one.

The preset only example is the case where you want the design system without the components. The UnoCSS preset carries the theme, the dynamic colour generation and the resolver, and you write plain markup with utility classes. Nothing from the Vue component layer is imported, so the dependency surface is smaller and the styling remains entirely yours.

The vite-onu-vue example is the case where you want the components. Here the Vue component library is the reason you installed the package, and the preset is there to supply the theme and the utilities the components are built from.

That split is the library's real proposition. A component library written in the atomic CSS style can be useful to a team that wants the visual language but not the abstractions, and a team that wants the abstractions should not be forced to hand-write the same button and dialog. The two examples exist to show that both routes are supported, which is why the phrase opinionated in the description is not in tension with the preset only option.

The credits also give you a sense of the design references: daisyui for the component patterns and @nuxt/ui for the Vue layer, both rebuilt here as UnoCSS-native components with the Magicolor theme on top.

The release history is the thing to check first

The README header says Onu UI (WIP), and the version numbers do not contradict it. The published npm versions are v1.1.2 on 2024-09-04, v1.1.3 on 2024-11-09 and v1.1.5 on 2024-11-10, and the repository's own package.json carries version 1.1.5.

The repository is not archived, and the last push was on 2026-08-21, which is well after the last release. So there is a gap of roughly a year between the published package and the current state of the source tree.

That gap has two practical consequences. The version in your lockfile tells you little about how current the code you would get from the repository is, and the work in the repository after the v1.1.5 tag is not something you get by installing from npm. If you are evaluating this library, the question to ask is not whether the project is active, since the pushes show it is, but whether the published version is the version you want.

The version numbering also has gaps, with 1.1.2, then 1.1.3, then 1.1.5, which is the pattern of a project that ships quickly and does not always publish a patch for every commit.

The licence is MIT, with the licence text in the repository and a copyright line naming Chris. That part is not in doubt.

Where Onu UI is the wrong tool

The first wrong case is a project that has not committed to UnoCSS. The library is built on the assumption that you have UnoCSS configured with its preset, and the pure atomic css feature means the components do not carry their own CSS. Without the preset, there is no theme and the components have nothing to draw on. A team that wants a self-contained component library with its own stylesheet should look at a library that ships one.

The second wrong case is a project that needs a supported release. The documentation itself says WIP, the last npm version is from 2024, and there is no visible changelog discipline in the repository listing. A team whose design system is depended upon by other teams, or that needs to answer a security question about a dependency, is in a difficult position with a package whose published version predates the current source by a year.

The third is a project that wants full control of the palette. The Magicolor generated theme is a feature and a constraint at the same time. If your brand colour must be an exact value, or your design system has a token pipeline that produces the colours, then a library that generates its palette and offers a dark mode you did not design is a source of friction rather than help. The alternative in that case is to use the UnoCSS preset on its own, without the components, and keep the theme generation in your own build.

That last option is worth weighing on its own merits, because it is a smaller commitment with the same visual result. Onu UI gives you two things: a theme generated from perceptual rules, and a set of Vue components that use it. If you only need the first, the UnoCSS preset and the resolver are enough, and you avoid depending on the component layer's release cadence. The examples directory exists to let you evaluate exactly that split before committing.

Editorial conclusion

Onu UI fits a Vue team that has already chosen UnoCSS and wants components that match the atomic CSS approach rather than a traditional stylesheet library. It is the wrong choice if you need a maintained release cadence, since the last published version is v1.1.5 from 2024-11-10 while the repository header still says WIP. Before you depend on it, read the documentation site for the resolver and theme setup, check that the UnoCSS preset you use is compatible with the atomic CSS assumption, and confirm the package version your lockfile pins rather than tracking the main branch.

Frequently asked questions

Official sources

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