Spectrum UI ships component source, not a package, and checks its own registry

Nothing is hidden behind a package

The defining claim is in the README's first section: nothing is hidden behind a package. The source lands in your project and from there it is yours to change.

That is the copy-paste distribution model, and it has real consequences. You do not get semver, a changelog or an upgrade path. You also do not get a bug fixed for you, since a component you copied three months ago is your code now. In exchange there is no version negotiation, no bundle-size argument and no breaking change to schedule around, which is the trade shadcn/ui popularised.

The stack underneath is stated plainly: React components built on shadcn/ui, Tailwind CSS and Motion. The site itself is Next.js 14 on the App Router with TypeScript, Tailwind, Radix and Motion, and the accounts, email and hosting are Supabase, NextAuth, Resend and Vercel.

The catalogue holds 250 plus components according to the README, along with page blocks and a few full templates. The categories are forms, cards, buttons, ratings, overlays, media, auth and feedback, plus hero, pricing, FAQ, CTA and footer blocks, dashboard and landing page templates, and a colour palette browser at the `/colors` route.

Every component page carries a live preview with the code underneath it, so the docs site is the documentation.

Three ways in, and two of them need the shadcn CLI

There are three acquisition routes and they differ in what they require of your project.

The MCP server route lets an editor install components for you. Registering it is one command:

claude mcp add spectrum-ui -- npx -y @spectrumui/mcp

Once connected, the README describes the interaction as simply stating what you want, for example asking for a kanban board and an animated drawer. Setup for Cursor and Windsurf is documented separately on the MCP docs page. A `.mcp.json` file in the repository root and an `.agents/` directory show the project expects agent-driven workflows, and `.husky/` suggests git hooks are wired in.

The shadcn CLI route is the middle path and it assumes your project is already configured:

npx shadcn@latest add @spectrumui/animated-drawer

That command form is the giveaway: components are addressed by namespaced registry identifiers, which means a `components.json` in your project has to point at a registry that knows the `@spectrumui` scope. The repository has its own `components.json` and a `registry.json`, so the pattern is consistent, but a project without shadcn set up has to do that work first.

The third route is manual. Open a component page, hit copy, paste it in. That works regardless of your setup, which makes it the fallback when the CLI route refuses.

Worth being clear about: none of these three is a package install in the npm dependency sense. `npx` fetches the installer, and the installer writes source files into your tree.

One component touches five places in the repo

The contribution section documents the file layout for a single component, and it is the clearest picture of how the catalogue is wired together. A component is a few files: the source in `components/spectrumui/`, a docs page under `app/(docs)/docs/`, registry entries in `registry.json` and `public/r/`, and a line in `content/component-catalog.json`. The README suggests copying an existing component and following its shape as the fastest route.

Five touch points for one component is the cost of the model. The registry is what the CLI and the MCP server read; `public/r/` holds the served copy; the docs page is what a human sees; and the catalogue JSON is the metadata other pages consume.

That is why the repository is full of generator scripts. The `package.json` defines paired generate and check targets: `generate:llms` and `check:llms`, `generate:component-docs` and `check:component-docs`, `generate:card-snippets` and `check:card-snippets`, and `generate:registry` with `check:registry-generated`, each backed by a script under `scripts/`. The check variants exist so drift is detectable rather than silent.

The composed test script chains the checks together:

npm run test:registry && npm run test:registry-integrity && npm run check:registry-generated && npm run test:catalog && npm run test:component-docs && npm run check:card-snippets

Individual suites exist for charts, metadata, structured data and topic hubs, each a separate file under `tests/`. The `test` script in package.json chains registry, registry integrity, generated registry output, the catalogue and component docs, and the README summarises `yarn test` as checking that the registry, catalogue, metadata and structured data line up. Contributors are asked to run it before opening a pull request.

Running the catalogue site needs three keys you may not have

Working on the components is different from using them. The README is explicit that the local setup is only needed if you want to work on the site itself:

git clone https://github.com/arihantcodes/spectrum-ui.git
cd spectrum-ui
yarn install
yarn dev

That serves localhost:3000, and the docs, components and registry work out of the box. The four scripts are `yarn dev` for the dev server, `yarn build` for a production build, `yarn lint` for ESLint and `yarn test` for the consistency checks. Note the package manager is yarn for local development while `package-lock.json` sits in the repository root, which is a small inconsistency worth resolving in your own fork.

Auth, payments and bookmarks are different. The README states those pages need keys in a `.env` file and will be quiet until you add them. The repository makes the stack visible: `auth.ts` and `proxy.ts` at the root for NextAuth, `dodo-seed.sql` and `pro-waitlist.sql` for the payments and waitlist paths, plus `models/`, `hooks/`, `lib/`, `type/` and `types/` directories.

That split is the right design for a component catalogue. Most contributors never touch Supabase or Resend, and the pages that do require them are clearly marked as needing configuration.

Where this sits against shadcn/ui, Magic UI and Aceternity

The repository description credits Aceternity UI, Magic UI and shadcn/ui as the foundations, which makes the relationship with those projects worth being precise about rather than glossing over.

The difference between Spectrum UI and them is volume and curation: 250 plus entries with a documented contribution shape and consistency tests, against collections that vary in how carefully each entry is maintained.

Against building your own: a design system assembled by one team is coherent by construction. A catalogue assembled from many sources has coherence problems that show up as inconsistent spacing, focus rings and animation timing across components that were never designed to sit next to each other. The presence of `components.json` and a Tailwind-based base helps, but it does not remove that risk.

The honest framing is that Spectrum UI optimises for starting speed. That is a real benefit for a prototype or a small product, and a real cost for a codebase that needs one coherent, owned design system with a maintainer attached to it.

Apache-2.0, no releases, and a roadmap file in the repo

Licensing is Apache 2.0 with the LICENSE file at the root, which is more permissive than the MIT many component collections use, since it includes an explicit patent grant. For copied component source in a commercial product that is the friendlier of the two, and the notice must be retained.

The repository has no GitHub releases, and the package manifest is marked private with version `0.1.0`, which tells you how the project itself sees its release process: the site is deployed continuously and the components ship unversioned. There is no upgrade command and no migration path between catalogue revisions. That is the accepted cost of the copy-paste model, and it is the main reason to copy a component once and own it rather than re-syncing periodically.

Maintenance signal: the repository is not archived and the last push was on 2026-09-21. Whether the catalogue keeps growing is not something the README answers.

Three files in the root are unusual enough to mention, because they describe the project rather than the code. `AI_SEARCH_GEO_STRATEGY.md`, `design-engineer-blog-seo.md` and `Q2_2026_PLAN.md` are planning and content documents, alongside a `.agents/` directory and `docs/`. If you are evaluating the project's direction, the plan file is more informative than the component count. If you are evaluating the components, ignore them.

Editorial conclusion

Spectrum UI suits a team that wants owned component source rather than a dependency to track, and its `yarn test` gate is a genuine advantage as a catalogue grows. Do not reach for it if you want a versioned, supported library with a changelog, because there are no releases and the components arrive unversioned into your codebase with you owning every future fix. Verify first that your project already has shadcn/ui configured, since the CLI route assumes it and the MCP route installs through the same registry.

Frequently asked questions

Official sources

1. arihantcodes/spectrum-ui on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README