DEV Community

Cover image for Why I Chose Copy-and-Paste Components Instead of an npm Package
Vladyusha
Vladyusha

Posted on

Why I Chose Copy-and-Paste Components Instead of an npm Package

If you've used React for a while, you've probably installed dozens of UI libraries.

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

It feels like the obvious solution.

So when I started building Motoko UI, I asked myself:

Should this be another npm package?

The answer surprised me.

I decided not to build a traditional component library.

Instead, every component is copied directly into your project.

Here's why.


You Own the Code

One thing always bothered me about traditional UI libraries.

The moment you install them, part of your application lives inside node_modules.

If you need to tweak a component, you have three options:

  • Override styles
  • Wrap the component
  • Fork the library

None of them feels ideal.

With copy-and-paste components, the code becomes yours from day one.

Rename it.

Refactor it.

Delete half of it.

Change every animation.

No restrictions.


No Black Boxes

One of the best ways to learn React is by reading real components.

When the code is inside your project, everything is transparent.

You can immediately see:

  • how state is managed
  • how animations work
  • how accessibility is handled
  • how styles are structured

Nothing is hidden behind an API.


Easier to Customize

Every project has different requirements.

Different colors.

Different spacing.

Different animations.

Different coding styles.

Instead of designing hundreds of configuration options, I prefer something much simpler:

Just edit the component.


Better Long-Term Stability

Traditional packages evolve.

APIs change.

Breaking changes happen.

Version conflicts appear.

With copy-and-paste components, your project doesn't suddenly break because of a package update.

The component becomes part of your codebase.

You decide if—and when—to update it.


Less Dependency Weight

Every dependency introduces maintenance.

Even a small package has to be:

  • installed
  • versioned
  • updated
  • audited
  • kept compatible

Copy-and-paste components avoid adding another runtime dependency.

Once the component is in your project, it's simply your code.


Why the Registry Matters

Copying code manually doesn't scale very well.

That's why Motoko UI uses a registry compatible with the shadcn CLI.

Installing a component is as simple as:

npx shadcn@latest add @motokoui/theme-switcher
Enter fullscreen mode Exit fullscreen mode

The CLI copies the files directly into your project.

No runtime package.

No hidden abstraction.

Just React components you own.


Are npm Packages Bad?

Not at all.

They're the right choice for many things:

  • state management
  • routing
  • data fetching
  • utilities

But UI components are different.

They almost always need customization.

For that reason, I think owning the source code is a better developer experience.


Final Thoughts

Building Motoko UI changed the way I think about component libraries.

Instead of creating another package that developers depend on, I wanted to create a collection of components they could truly own.

That philosophy influences every decision in the project—from the registry to the documentation to the component APIs.

I'm curious where the React ecosystem goes next, but for now, I believe copy-and-paste components offer one of the best experiences for building modern applications.

If you've built a component library yourself, I'd love to hear which approach you prefer: traditional npm packages or copy-and-paste components?

Top comments (0)