Kibo UI: a component registry with no install command and two lockfiles in one repository

The readme has no install line, only a link to another site

The Installation section of the readme contains one sentence and one link: read the docs, pointing at kibo-ui.com. There is no command, no package name, no registry URL and no configuration step in the repository itself. Everything a user needs in order to install and use this project therefore lives outside the repository.

That is unusual for a component library, and it has a concrete consequence. The npm package exists, and the manifest declares it, but the readme never mentions it, so someone reading GitHub cannot tell whether the components are installed with a package manager, copied as source through the shadcn CLI, or both. The overview does say the components use the shadcn/ui CSS variables and are designed to work with the existing primitives, which points at the copy-in model, but it never names the mechanism.

Everything else in the readme is positioning. It describes the registry as a collection of building blocks intended to reduce boilerplate without sacrificing flexibility and responsive design, and it positions itself against shadcn/ui itself, which it says focuses on wrapping primitives from Radix UI.

The manifest ships one file and declares no import entry point

The package manifest names the package kibo-ui at version 1.1.5, sets `"type": "module"`, and declares a binary and a file list.

"bin": {
  "kibo-ui": "dist/index.js"
},
"files": [
  "dist/index.js"
]

The file list has exactly one entry, the same path the binary points at. So the published tarball is a single JavaScript file, and the package exposes it as a command line program. What the manifest does not contain is a main field, a module field, an exports map or a types field. A consumer who installs the package and tries to import a component from it finds no declared entry point to resolve.

Whether that is a bug or a deliberate choice is not stated anywhere. If the intended install path is copying component source into your own project rather than importing a library, then the binary is the only supported surface and the omission is harmless. The readme does not say so, and neither does the manifest.

Two lockfiles sit in a root that declares pnpm as its package manager

The top level of the repository contains both `package-lock.json` and `pnpm-lock.yaml`, alongside `pnpm-workspace.yaml`. The manifest names `[email protected]` in its packageManager field, and the dependency bump script ends with `pnpm install`, so the intent is clear: this is a pnpm workspace with a turbo pipeline over an `apps/` directory and a `packages/` directory.

The npm lockfile is the leftover. Committing two lockfiles in one root is a known source of install drift, since the two tools resolve the same manifest differently and each will rewrite the tree to match its own resolution. Nothing in the repository indicates which one is authoritative, and the readme does not mention either.

There is also a workspace root that mixes concerns. `turbo.json` and `tsup.config.ts` describe the build, `biome.jsonc` describes linting, `next-env.d.ts` implies at least one Next.js app, and `scripts/` sits alongside all of it. The engine floor is Node 18 or newer, with TypeScript at ^5.9.3 and turbo at ^2.5.8 pinned in devDependencies.

The dependency bump script excludes four packages on purpose

Two scripts in the manifest do the maintenance work, and both are more specific than a generic update would be.

"bump-deps": "npx npm-check-updates --deep -u -x shiki,next,recharts,require-in-the-middle && pnpm install"
"bump-ui": "npx shadcn@latest add --all --overwrite -c packages/shadcn-ui && npx shadcn@latest migrate radix -c packages/shadcn-ui"

The first runs npm-check-updates with `--deep` and excludes four names: shiki, next, recharts and require-in-the-middle. Those exclusions are not explained in the repository, which is a maintenance note worth asking about before you run it, since an unexplained exclusion list is where dependency drift accumulates. It then runs a full install.

The second is the interesting one. It pulls every component from the shadcn CLI with `--all --overwrite` into `packages/shadcn-ui`, then runs `shadcn migrate radix` against the same path. So upstream components are copied in wholesale and then migrated, which means the upstream registry is the source of truth for the primitives and a migration step sits between it and this project. Neither script is mentioned in the readme.

Two lint configurations and a clean script that reaches past the project

Linting is configured twice. The root has `biome.jsonc`, and the manifest depends on `ultracite` at ^6.0.0 while routing both check and fix through it:

"check": "npx ultracite@latest check",
"fix": "npx ultracite@latest fix"

Two things are worth noticing. The scripts invoke `ultracite@latest` through npx, so the version in devDependencies is not the version that runs, and the two can disagree. And a config file for one tool sits next to a dependency on another that wraps it.

The clean script is the other one to read before you run it.

"clean": "git clean -xdf node_modules"

`git clean -xdf` removes untracked and ignored files across the repository, and passing node_modules as a path narrows it to that directory. Narrow is the only reason this is safe to have in a manifest, and it is still the one script here with a blast radius, so it is worth checking your working tree first.

Two patch versions shipped four minutes apart

The release history has three entries. v1.1.3 was published on 30 August 2025, then v1.1.4 and v1.1.5 were both published on 29 October 2025, four minutes apart at 05:36 and 05:40 UTC. Two patch versions in the same morning is what a re-release after a packaging problem looks like, although the repository does not say what changed in either.

The manifest version is 1.1.5, which matches the newest tag, so the working tree and the release line agree. The last commit to the default branch main is dated 4 May 2026, about six months after that release. So the branch has moved since 1.1.5 shipped, and the changelog file in the root is where those changes are recorded.

The release tooling is visible too. The devDependencies include `@auto-it/first-time-contributor`, and the root has an `.autorc` configuration file, so part of the release path is automated rather than run by hand. There is also a `.coderabbit.yaml` and a `.cursor/` directory, both aimed at automated review in editors.

The readme positions Kibo UI against shadcn/ui rather than listing components

With no component list, no props tables and no examples, the readme does three things. It states that the components use the shadcn/ui CSS variables and are meant to work with the existing primitives. It describes the components as building blocks for more complex components, meant to cut boilerplate. And it draws a line against shadcn/ui, which it says focuses on wrapping primitives from Radix UI while Kibo UI is meant to be a broader library wrapping more complex logic from various headless libraries.

That is a positioning statement, not a specification. Nothing in the repository says which components exist, what props they take, which headless libraries are wrapped, or which accessibility behaviour they implement, even though accessible is one of the three adjectives in the project description. The contributors section is a graph embed, and the licence is MIT in a file named `license.md` in lowercase.

The repository therefore answers what the project is for and answers nothing about how to use it. For a registry whose whole value is in its components, that gap has to be closed on the documentation site before you can evaluate any of it.

Editorial conclusion

Kibo UI is worth a look if you build with shadcn/ui and want components that wrap more logic than a single Radix primitive, and you should plan on reading the external documentation rather than the repository. Check the published package before you depend on it: the manifest ships one file and declares no import entry point, and the latest release is v1.1.5 from 29 October 2025 while the last commit is dated 4 May 2026. If you clone it, delete whichever lockfile does not match your package manager before installing, and run the dependency bump script with care because it rewrites the workspace.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. shadcnblocks/kibo on GitHub