A small TypeScript check can catch a plausible but nonexistent component import before it becomes part of your next React feature.

A generated React component can look convincing while importing an API that its package does not export. The failure is easy to miss in a code review: the component name exists, the package name exists, and the combination feels reasonable. A small compiler check gives you a concrete answer before that code spreads across a feature.

We maintain Ninna UI. This article was drafted with AI assistance; its import examples were checked with TypeScript against installed Ninna UI 0.7.0 packages. The example is a controlled reproduction, not a claim about how often any coding agent makes this mistake.

The plausible import that fails

Ninna UI splits components across public packages. Button belongs to primitives, Modal belongs to overlays, and VStack belongs to layout. Here is a deliberately incorrect import:

import { Modal } from "@ninna-ui/primitives";
void Modal;

With the installed 0.7.0 declarations, TypeScript reports TS2305: the primitives module has no exported member named Modal. The fix is to import Modal from @ninna-ui/overlays. Renaming it, installing an unrelated dependency, or adding a local declaration would conceal the underlying mismatch.

Create a tiny audit file

Use an existing React and TypeScript project. If these packages are missing, install only the public packages used by the example. In a new project, use the current packages; keep the lockfile so the check has a reproducible version.

pnpm add @ninna-ui/core@latest @ninna-ui/primitives@latest @ninna-ui/overlays@latest @ninna-ui/layout@latest
pnpm add -D typescript @types/react @types/react-dom

Create ui-import-audit.ts in your project root. The file deliberately renders nothing. Referencing each import keeps the audit focused on the public values you expect the package to expose.

import { Button } from "@ninna-ui/primitives";
import { Modal } from "@ninna-ui/overlays";
import { VStack } from "@ninna-ui/layout";

// This checks imports; it renders no UI.
void [Button, Modal, VStack];

Give the check a clear boundary

Create tsconfig.ui-audit.json beside the file. This isolated configuration checks one fixture without pulling in every application route. The bundler resolution setting is appropriate for this bundled React example; use your framework's supported configuration for the application itself.

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "types": ["react"],
    "strict": true,
    "skipLibCheck": true,
    "noEmit": true
  },
  "include": ["ui-import-audit.ts"]
}

pnpm exec tsc -p tsconfig.ui-audit.json

The corrected fixture should exit successfully. Then make the known wrong change: import Modal from primitives. Run the same command and confirm that it fails with TS2305. Restore the correct import and confirm success again. That negative control checks that your audit is actually compiling the file you think it is.

The noEmit option prevents JavaScript output. skipLibCheck skips checking declaration-file internals; it does not exempt the imports in your audit file from type checking. If the check reports a missing package instead, verify the installation and the directory from which you ran it before changing compiler settings.

Give your agent an acceptance condition

A package map helps an agent choose an import. An executable check helps you decide whether to accept the result. Put a short task-specific rule in the project's agent instructions, and keep the actual public API reference close to the task.

Before changing a React UI import:
1. Check the installed package's public export and the current docs.
2. Import Button from @ninna-ui/primitives.
3. Import Modal from @ninna-ui/overlays.
4. Import VStack from @ninna-ui/layout.
5. Run the import audit, then the application's normal typecheck and build.
Do not silence an import error with any, @ts-ignore, or a fabricated module declaration.

For this reproduction, TypeScript 5.9.3 and React 19.2.8 checked Ninna UI 0.7.0. The corrected three-import fixture produced no diagnostics; the deliberately incorrect Modal import produced TS2305. When you upgrade packages, rerun the check instead of assuming an old article still describes the installed release.

What passing this check does not prove

A correct import is only one part of a working UI. This fixture does not render a modal, open a browser, inspect CSS, or measure a bundle. It also cannot prove that published runtime code agrees perfectly with its declarations.

• Run the application's normal typecheck to check real props and composition.
• Run a production build to check bundler integration and package resolution.
• For rendered Ninna UI examples, follow the installation guide's CSS imports and root data-theme setup. An import-only fixture needs no CSS because it renders nothing.
• Check actual interactive behavior: labels, keyboard navigation, focus movement and error states. Compiler success is not an accessibility audit.
• Keep runtime tests for behavior you depend on. This import check complements them; it does not replace them.

The useful result is modest: a plausible import becomes a checked dependency boundary. Start with the few APIs a generated feature needs, prove the check can fail, and keep the application's broader checks in the acceptance criteria.

References

TypeScript: module resolution options

TypeScript: noEmit

TypeScript: skipLibCheck

Ninna UI installation and CSS setup

Ninna UI package map and agent reference

Two years later, both approaches have proven themselves in production. This article is an honest comparison of the copy-paste model (shadcn/ui) and the npm package model (Ninna UI) - examining the trade-offs that matter at scale.

The Two Models

shadcn/ui: Copy-Paste

You run a CLI command that copies React component source files directly into your project. The components use Radix UI primitives and Tailwind CSS for styling. You own every line of code.

npx shadcn@latest add button dialog select

This creates files in your components/ui/ directory. They're yours. Modify them freely.

Ninna UI: npm Packages

You install packages from npm. Components are consumed as imports. You customize via CSS custom properties, Tailwind utilities, and data-slot CSS selectors - without modifying source code.

pnpm add @ninna-ui/primitives @ninna-ui/overlays @ninna-ui/forms

import { Button } from "@ninna-ui/primitives";
import { Modal } from "@ninna-ui/overlays";
import { Select } from "@ninna-ui/forms";

The Trade-Offs

1. Updates and Maintenance

shadcn/ui: When a bug is fixed upstream, you have two options:

• Re-copy the component (losing your customizations)

• Manually apply the patch to your local copy

There's no npm update. No changelog. No semantic versioning. Each project has a unique fork that diverges from upstream over time.

Ninna UI: Standard npm workflow. pnpm update @ninna-ui/primitives gets you bug fixes, accessibility improvements, and new features - while preserving your customizations (which live in CSS, not in component source).

pnpm update @ninna-ui/primitives
# Changelog at https://ninna-ui.dev/changelog

Verdict: npm packages win for teams that value maintenance predictability. Copy-paste wins for developers who rarely need upstream updates.

2. Customization Depth

shadcn/ui: You own the code. You can change anything - the component structure, the HTML output, the ARIA behavior, the prop API. There's no abstraction between you and the implementation.

// You can literally rewrite the component
export function Button({ className, ...props }) {
  return (
    <button
      className={cn("my-completely-custom-button-styles", className)}
      {...props}
    />
  );
}

Ninna UI: You customize via 3 layers without touching source code:

1. Tailwind utilities - className prop on every component

2. CSS custom properties - theme tokens (--color-primary, --radius-lg)

3. data-slot selectors - target any internal element

/* Customize any internal element via CSS */
[data-slot="trigger"] {
  border-radius: var(--radius-full);
  font-weight: 600;
}

[data-slot="content"] {
  animation: slide-down 200ms ease-out;
}

98 data-slot targets cover every customizable element across all 69 components - without forking a single file.

Verdict: shadcn/ui wins for unlimited structural changes. Ninna UI wins for styling customization without the maintenance cost of owning source code.

3. Cross-Project Consistency

shadcn/ui: Each project gets a unique copy of every component. Over time, these diverge. A Button in Project A is different from Button in Project B. Keeping them synchronized requires manual discipline or a private component library (which is... an npm package).

Ninna UI: Every project uses the same @ninna-ui/primitives version. Same API, same accessibility, same behavior. Different visual styles via CSS theme presets - but the component contracts are identical.

/* Project A: Default theme */
@import "@ninna-ui/core/theme/presets/default.css";

/* Project B: Ocean theme */
@import "@ninna-ui/core/theme/presets/ocean.css";

/* Same components, different look */

Verdict: npm packages win decisively for multi-project teams and agencies.

4. Dependency Management

shadcn/ui: Each copied component may depend on specific Radix UI packages. A typical shadcn/ui project accumulates 10-15+ Radix packages:

{
  "@radix-ui/react-dialog": "^1.x",
  "@radix-ui/react-dropdown-menu": "^2.x",
  "@radix-ui/react-select": "^2.x",
  "@radix-ui/react-tooltip": "^1.x",
  "@radix-ui/react-popover": "^1.x",
  "@radix-ui/react-accordion": "^1.x",
  "class-variance-authority": "^0.7",
  "cmdk": "^1.x",
  "lucide-react": "^0.x"
  // ... more for each component
}

You manage version compatibility yourself. When Radix releases a breaking change, you update each component individually.

Ninna UI: Radix is an internal implementation detail. You never import it. You never manage its versions. Ninna UI wraps 11 Radix primitives behind clean interfaces:

{
  "@ninna-ui/primitives": "^0.4.1",
  "@ninna-ui/overlays": "^0.4.1",
  "@ninna-ui/forms": "^0.4.1"
}

Three dependencies instead of fifteen. Radix version management is Ninna UI's responsibility, not yours.

Verdict: npm packages win for dependency hygiene. Copy-paste forces you to be a Radix version manager.

5. Bundle Size

shadcn/ui: You only include the components you use, and since they're local files, tree-shaking is perfect. No unused code reaches the bundle.

However, each component pulls its own Radix dependency, and multiple components may include overlapping utility code (cn(), cva(), etc.).

Ninna UI: 12 tree-shakeable ESM packages with sideEffects: false. Import only what you use - unused components are eliminated by your bundler.

The theming layer is pure CSS (zero JavaScript), which means your theming overhead is literally 0 KB of JavaScript. shadcn/ui's theming is also CSS-based, so this is roughly equivalent.

Verdict: Roughly equal. Both approaches tree-shake well. Ninna UI has a slight edge because Radix dependencies are deduplicated internally.

6. TypeScript Experience

shadcn/ui: Types depend on how well you maintain the copied code. Out of the box, components use cva for variant typing, which provides basic prop safety. But types can degrade as you modify components.

Ninna UI: Full TypeScript generics on every component, maintained by the library team. Generic Select<T>, discriminated union props, strict event handlers:

type Role = "admin" | "editor" | "viewer";

<Select<Role>
  options={[
    { value: "admin", label: "Admin" },
    { value: "editor", label: "Editor" },
  ]}
  onChange={(role) => {
    // role is typed as Role, not string
  }}
/>

Verdict: Ninna UI wins for type depth and consistency. shadcn/ui types are "good enough" but degrade with customization.

7. Accessibility

Both use Radix UI primitives, so the accessibility foundation is identical. The difference is maintenance:

shadcn/ui: When Radix improves accessibility (new ARIA patterns, better screen reader support), you must manually update your copied components to benefit.

Ninna UI: Accessibility improvements ship via npm update. You get them automatically.

Verdict: Equivalent at install time. Ninna UI wins over time because updates are automatic.

Decision Framework

Choose shadcn/ui if:

• You're a solo developer or small team

• You want unlimited structural control over components

• You rarely need upstream updates

• You're comfortable managing Radix dependencies

• You enjoy customizing component internals

Choose Ninna UI if:

• You work across multiple projects

• You want standard npm maintenance (update, audit, semver)

• You prefer CSS customization over source code modification

• You want Radix accessibility without managing Radix directly

• You need consistent component behavior across your organization

Choose both if:

• You want the npm package model for most components

• But need to fork specific components for edge cases

Ninna UI's data-slot CSS API means you'll rarely need to fork. But when you do, nothing stops you from copying one component's source and customizing it.

The Bigger Picture

The copy-paste vs npm debate isn't really about shadcn/ui vs Ninna UI. It's about two different philosophies:

Copy-paste says: "Libraries are constraints. Own your code."

npm packages say: "Libraries are leverage. Own your product."

Both are valid. But the npm model has 20 years of proven infrastructure - semantic versioning, changelogs, automated updates, dependency auditing, security patches - that the copy-paste model intentionally abandons.

In 2026, with React Server Components, Tailwind CSS v4, and the increasing complexity of web accessibility requirements, the case for professional-grade npm packages has never been stronger.

Try Ninna UI

npx @ninna-ui/cli init my-app

→ Documentation → shadcn/ui vs Ninna UI comparison → All library comparisons