# components.build is a written standard for open source UI components > The components.build project is a formal specification, co-authored by Hayden Bleasel and shadcn, that tells maintainers what a modern open source UI component should be, along six axes from composability to full code ownership. It suits maintainers of component libraries who want a checklist and a vocabulary rather than another package to install. **vercel/components.build** — An open-source standard for building modern, composable and accessible UI components. - Repository: https://github.com/vercel/components.build - Website: https://components.build/ - Stars: 801 · Forks: 57 - Language: MDX - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/vercel-components-build ## A specification rather than a package The framing in the README is deliberate. components.build is a formal specification that establishes best practices and guidelines for building open-source UI components for the modern web, co-authored by Hayden Bleasel and shadcn, and the stated aim is to help open-source maintainers and senior front-end engineers create components with particular qualities. The topic list of the repository carries the words registry and shadcn-ui, which places it in the world of registries where component code is copied into a project rather than installed from it. That connection is what makes the word transparent in the quality list meaningful. In a registry model the user ends up owning the code, and the specificationification is the contract that the copied code is expected to meet. ## The six qualities, and what each one demands The specification is organised around six properties, and they are worth reading as a definition rather than as a slogan list. Composable means built with composition over inheritance, so components can be combined to create complex interfaces rather than extended. Accessible means WCAG-compliant with proper ARIA attributes and keyboard navigation. Customizable means easy to theme and style for any design system. Performant means lightweight with minimal dependencies. Transparent means full code visibility and ownership. Well-documented means clear examples and a developer-friendly experience. Two of these pull against each other in a way that makes the specificationification useful rather than decorative. A component that is maximally transparent and owned by the user tends to accumulate local modifications, while one that is heavily customised and abstracted tends to hide the code again. ## Accessibility as a property of the component, not a later audit The accessibility clause is the one with the most specific requirements, and it is phrased as something the component is rather than something a team should check later. WCAG-compliant, with proper ARIA attributes and keyboard navigation, are listed as part of the definition of a good open source component. That framing has an effect on how a library is built, because the ARIA roles and the keyboard handling have to be part of the component's own code, and the fact that the specificationification mentions proper ARIA attributes specifically suggests the roles are expected to be carried by the component rather than left to the consumer to add to the wrapper. The README also links to a contributing guide and says the specificationification is informed by the open-source community and real-world component libraries, so the criteria are intended to be applied against code that exists rather than written in the abstract. ## React in the examples, framework agnostic in the principles There is an explicit note about scope in the README. While the examples use React and TypeScript, the core principles are framework-agnostic and applicable to Vue, Svelte, Angular and other modern frameworks. That is a sensible division, since composability, accessibility and documentation are properties of a component's design rather than of a particular rendering library. The examples are the more detailed part of the repository in practice, since the content is written as MDX and rendered by a documentation stack. The `package.json` shows that stack: Next.js 16 with React 19, `fumadocs-mdx` and `fumadocs-core` for the documentation layer, `fumadocs-ui` for the components, and MDX content with `source.config.ts` and a `postinstall` hook that runs `fumadocs-mdx` so the MDX is compiled as part of install. ## The site itself is the working example of the standard The repository is not just a document, it is a documentation site built with the kind of component stack the specificationification describes, and it uses the component ecosystem it is about. The dependency list includes `radix-ui`, `lucide-react` for icons, `class-variance-authority` and `clsx` and `tailwind-merge` for class composition, `cmdk` for command palettes, `sonner` for toasts, `vaul` for drawers, `motion` for animation, `shiki` for syntax highlighting, `zod` for validation, `next-themes` for theming, `jotai` for state, `dexie` for the local database layer and `tailwindcss` 4 with `tw-animate-css`. The `components.json` file in the root is the registry configuration, and there is a `components/` directory alongside `content/`, `app/`, `hooks/`, `lib/`, `scripts/` and `skills/`. ## Translation, skills and the tooling around the specification Two directories hint at where the project is heading. There is a `skills/` directory with a `sync:skills` script that runs `./scripts/sync-skill-docs.sh`, so parts of the documentation are kept in step with material aimed at coding agents, and there is a `translate` script that runs `npx @vercel/geistdocs translate`, with a `.translation-cache.json` at the root holding the state of that work. The linting and formatting run through `ultracite`, with `fix` and `check` scripts, and the formatting configuration is `biome.jsonc`. The development scripts are otherwise the usual Next.js set, with `build` running `next build`, `dev` running `next dev` and `start` running `next start`. The site is built with `geistdocs.tsx` as the docs component, and `proxy.ts` sits at the root, so the project is deployed as a real site rather than a PDF. ## MIT terms, an open contribution path, and the current state The README states that the project is open source and available under the MIT License, with the licence file at the root, while the platform classifies the repository licence as a custom one that it cannot map to a standard identifier, so the LICENSE file is the authoritative text. Contributions are welcome, and the route is a contributing guide in `.github/CONTRIBUTING.md`, with the README noting that the specificationification is informed by the open-source community and by real-world component libraries. There are no GitHub releases, so the specificationification has no versioned artefacts, and the repository is not archived with the last push on 2026-08-20. For a document, that is the right arrangement. A specification that people can read, argue with and improve in the open is more useful than one that ships as a tagged release nobody re-reads. ## Conclusion Adopt components.build as a review checklist and a shared vocabulary when you maintain or publish a UI component library, since the specificationification gives you concrete criteria to judge a component against rather than a set of rules to enforce at runtime. Do not adopt it as a library to install, because there is no package here, it is a document and the documentation site. Verify first which of the six qualities your existing components already meet, since composability and full code ownership are the two that usually need work, and note that the licence is described in the README as MIT while the platform classifies the repository licence as a custom one, so read the LICENSE file before you republish anything under it. ## FAQ ### What is components.build? It is an open-source standard, co-authored by Hayden Bleasel and shadcn, that establishes best practices and guidelines for building open-source UI components for the modern web, aimed at maintainers and senior front-end engineers. ### What qualities does the components.build specification require? Six: composable, built with composition over inheritance; accessible, WCAG-compliant with proper ARIA attributes and keyboard navigation; customizable; performant with minimal dependencies; transparent, with full code visibility and ownership; and well-documented. ### Is components.build limited to React? The examples use React and TypeScript, but the README states that the core principles are framework-agnostic and applicable to Vue, Svelte, Angular and other modern frameworks. ### How do I contribute to the components.build specification? Contributions are welcome, and the README points to the contributing guide in `.github/CONTRIBUTING.md`. The specification is maintained as a document in the repository, with no GitHub releases, so changes are made by pull request against the default branch. ## Sources - [Issues](https://github.com/vercel/components.build/issues) - [Project website](https://components.build/) - [README](https://github.com/vercel/components.build/blob/main/README.md) - [vercel/components.build on GitHub](https://github.com/vercel/components.build) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vercel-components-build