You can edit the button, and you inherit its upkeep
Change a shadcn/ui button in your own source file and you've made the project's central trade: you can shape the component around your product, and your team takes responsibility for that change. The README explicitly invites you to build your own component library. This suits a React team whose design keeps exceeding a packaged library's options. You don't have to wait for an upstream styling option. You can review a local change in the same pull request as the screen that needs it. It is a poor bargain if nobody wants to maintain the resulting files.
The full upstream checkout contains 6,073 files and roughly 594,885 lines of source, occupying 49.5 MB before installation. That is the publishing and development monorepo, including the website and registry, rather than the code every consuming application receives. Keep that distinction in mind when choosing how to start. Editing components in your application and contributing changes to shadcn/ui itself involve different amounts of machinery.
What happened when we ran it
Our run installed 1,680 packages in 61 seconds and occupied 1,523 MB on disk. We cloned commit 02cad61 on October 12, 2026, into a fresh Debian sandbox with 3 CPUs and 8 GB of RAM, using the lab-node:22 image. The container was unprivileged and held no secrets. Installation succeeded, so the first obstacle appeared after the dependency download had finished.
The build failed with exit code 1 after 78 seconds. The log shows the shadcn package completing its build before the v4 workspace reports sh: 1: bun: not found. Its task summary records 4 successful tasks out of 5, with v4#build failing. That tells us an invoked Bun command was unavailable in the sandbox. It doesn't tell us whether the remaining work would succeed after Bun was supplied. For a contributor, the practical problem is immediate: the pnpm installation worked, while the subsequent build and test commands needed an executable that this container did not have.
The test command also failed with exit code 1, after 42 seconds. Its log stops during v4's registry:build, again reporting bun: not found, followed by spawn ENOENT. There is no assertion summary or passing-test count in the supplied tail. We cannot call this a failed component assertion. The checkable finding is that the repository's test command could not complete because a preceding registry step invoked an unavailable executable.
Our scan found 11 CI workflow files and a workspace monorepo, with no Dockerfile or tests directory reported. The missing directory signal doesn't establish that the project lacks tests. Together, these observations describe the checkout our harness encountered.
The consumer setup and contributor setup are separate jobs
The application setup guide directs users toward a framework-specific CLI route or adding components to an existing project. Your application needs its framework and styling configured. The components.json reference explains the CSS path and import aliases the CLI uses, and says copying code manually avoids that configuration file. Public component use doesn't require a paid service credential. Private registry access depends on the registry's authentication rules. The configuration reference says changing between CSS variables and utility classes requires deleting and reinstalling components, so that choice deserves attention early.
Cloning the 49.5 MB upstream repository takes you onto the contributor path. Its contributing guide describes pnpm workspaces and the website's generated registry assets. The root README offers little local-development guidance itself. For your own app, check the generated imports and theme settings before accepting a component.
October's CLI fixes still leave configuration review to you
Release shadcn@4.21.4 shipped on October 7, 2026. Its patch notes describe changes to the code that rewrites imports and configuration. Two entries explicitly say the CLI skips a Next.js font-layout edit or a Tailwind configuration edit with a warning rather than writing a broken file.
The repository was pushed on October 12, 2026, and GitHub listed 125,458 stars plus 1,787 open issues and PRs. Recent registry-directory submissions show ongoing contribution activity. Those dates support an active-project assessment, without promising response times across that queue. I prefer the CLI's caution around configuration edits, but an apparently finished operation can still leave work for you to do by hand. They also don't erase our 78-second build failure. Maintenance activity and a working contributor environment are separate pieces of evidence, and we have only the former confirmed here.
Pick a packaged library if component upkeep isn't your job
Mantine, at mantinedev/mantine, is my alternative for a React application that wants styled components and hooks maintained as packages. Material UI, at mui/material-ui, fits a team that wants Material Design conventions and an established packaged API. Radix Primitives, at radix-ui/primitives, suits developers who want low-level interaction components and intend to write the visual layer themselves. These are different maintenance choices. Pick according to who will own the component code after the initial screen is finished.
For a team building its own design system, shadcn/ui earns a trial because editable source is the deliverable. Our 1,523 MB installed checkout and blocked build make an upstream fork a more demanding commitment. Start with a component in your application, inspect the generated changes, and decide who will reconcile future upstream edits. If nobody can name that person, choose Mantine or Material UI before you start customizing the component files.