DEV Community

Cover image for You Should Own Your UI Components, Not Just Install Them
Sanjay Kumar Sah
Sanjay Kumar Sah Subscriber

Posted on

You Should Own Your UI Components, Not Just Install Them

#nextjs #shadcnui #architecture #opensource

One of my favorite ideas behind shadcn/ui has nothing to do with components. It's about ownership. Unlike most UI libraries, shadcn/ui doesn't ask you to install a package and hope the maintainers keep it stable forever. Instead, it generates the source code directly into your project.

Those components become yours. You can edit them. Refactor them. Delete them. There is no vendor lock-in.

When I started building create-notils, I realized this philosophy shouldn't stop at components. It should extend to the entire project.

Installing Dependencies vs. Owning Your Code

Most starter kits work like this:

npm install some-ui-library
Enter fullscreen mode Exit fullscreen mode

Your application now depends on another package. Every update means waiting for a new release, and every customization risks diverging from upstream. Sometimes you end up wrapping library components just to make them fit your project. Slowly, your application becomes a thin layer around someone else's code.

There's nothing inherently wrong with this approach, but I wanted something different.

Source Code Is the API

In create-notils, the generated project belongs to you. The UI components are copied into your repository. The configuration files are yours. The project structure is yours. Nothing is hidden behind an SDK.

That means changing a button isn't a breaking change—it's just another Git commit.

One Design System, Multiple Applications

One challenge with monorepos is avoiding duplicated UI code. Instead of installing shadcn/ui inside every individual application, create-notils keeps a single, shared design system at the workspace root:

packages/
└── ui/
    ├── components/
    ├── lib/
    └── styles/
Enter fullscreen mode Exit fullscreen mode

Every application imports components from the exact same package:

import { Button } from "@notils/ui/components/ui/button";
Enter fullscreen mode Exit fullscreen mode

When a new component is added, every application immediately has access to it. There is one source of truth, not three slightly different copies floating around your workspace.

Updating Isn't a Package Upgrade

One thing I always found awkward about UI libraries is updating them. Usually, it looks like this:

npm update some-library
Enter fullscreen mode Exit fullscreen mode

Then you read the changelog, hope nothing broke, and fix any breaking changes.

With shadcn/ui, updating is different because you're updating raw source files. In create-notils, the workflow is intentionally simple. Want to add a component?

bun ui:add dialog
Enter fullscreen mode Exit fullscreen mode

Need to see what changed upstream before you pull it in?

bun ui:diff button
Enter fullscreen mode Exit fullscreen mode

Ready to update?

bun ui:update button
Enter fullscreen mode Exit fullscreen mode

Every change is visible as a normal Git diff. No hidden abstractions. No magic.

The Same Philosophy Beyond Components

This release made me realize something: the idea of ownership applies to much more than just UI.

Authentication should live in your repository. Configuration should live in your repository. Database schemas should live in your repository. Generated code should be fully understandable without having to read a framework's internal source code.

That's the direction I want create-notils to move toward. I don't want to build a platform that owns your application. I want to build a platform that helps you own it.

Version 0.2.0 is Live

This release introduces the foundation for that philosophy. Highlights include:

  • Interactive project creation: Scaffold exactly what you need.
  • Monorepo and standalone generation: Two outputs from one canonical source.
  • Shared @notils/ui package: A unified design system for your workspace.
  • Built-in UI commands: Add, preview, and update shadcn/ui components effortlessly.
  • Dedicated developer guide: Generated specifically for your new project.
  • Better documentation & testing: For all generated applications.

The project is still early. Authentication, database integration, and additional capabilities are coming in future releases. But the core philosophy is already taking shape: Own your code. Reduce repetitive setup. Spend your time building products instead of rebuilding infrastructure.

Top comments (0)