npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@kanzo-tech/ui

v0.1.0

Published

Kanzo shared UI — Ark UI + tailwind-variants primitives (Level 1) and domain-free shells (Level 2), token-themed.

Vulnerabilities

Powered byPowered by Snyk
  • 0High
  • 0Medium
  • 0Low

Links

Git

Maintainers

angel-ipangel-ip

Keywords

Readme

@kanzo-tech/ui

Kanzo's shared UI surface — Ark UI behaviour, tailwind-variants appearance, design tokens between them. The component set is adopted from Shark UI and re-branded to the Kanzo tokens.

import "@kanzo-tech/ui/styles.css";
import { Button, KanzoThemeProvider } from "@kanzo-tech/ui";

What is in it

  • simples/ — one component, one job: the adopted primitive set (inputs, overlays, menus, navigation, data display) with a flat compound API — DialogTrigger and DialogContent, not Dialog.Trigger.
  • composites/ — assemblies of those that stay domain-free: the sidebar, the code editor, the Preferences theme panel.
  • layouts/ — the Shell and Section regions. Structure only, no appearance.

Everything is exported flat from the root, so a component moving between layers is never a breaking change. The docs site lists the surface with a live example per component, and its Philosophy page says how the three layers divide and what has to be true before a component is added.

Subpaths

The root barrel never statically imports an optional peer, because that would break import { Button } for everyone who did not install it. Anything that needs one lives on its own entry:

| Entry | Peer | |---|---| | @kanzo-tech/ui | none beyond React and lucide-react | | @kanzo-tech/ui/editor | @codemirror/* | | @kanzo-tech/ui/table | @tanstack/react-table | | @kanzo-tech/ui/analytics | @uwdata/vgplot, @uwdata/mosaic-*, @duckdb/duckdb-wasm |

Theming

KanzoThemeProvider writes the theme axes as data-* attributes on <html> — required, because Ark's overlays portal to document.body. useKanzoTheme() drives them, themeScript() prevents an SSR flash. Tokens and axes come from @kanzo-tech/theme.

Preference menus

The editor is a kit, not one screen. PreferencesColor, PreferencesDensity, PreferencesRadius and the two font axes are one preference each, wired straight to useKanzoTheme(); PreferencesField / PreferencesFieldSet title a section of your own the same way; PreferencesSections draws whatever the packages a host installed contribute. None of them knows what it is mounted on — PreferencesColor lays its two cards out under a container query, never a window width.

Preferences (and its PreferencesRoot / Trigger / Panel parts) is one surface over that kit: a non-modal drawer with a hotkey. A product with a real settings area drops the same sections into its own page instead, beside its own menu — no drawer, nothing to opt out of, no component to import for it. Both are first-class, and a section that ever needed to know which one it was on would be the design failing. The docs site shows the two side by side: showcases/metadata-form for the drawer, showcases/settings for the page.

Admission rule: nothing domain-specific — no RDF, SHACL, fossil, graph or auth knowledge.