fix(registry): rename lib files that share a basename with their UI file

KO
1d ago
+134-135

What and why

Follow-up to #136, which only fixed half of #135.

When a component's lib file has the same basename as its UI file, the shadcn CLI resolves the lib import to the UI file. The .ts extension from #136 fixed fresh installs. On shadcn add --overwrite the CLI resolves against files already on disk and still picks the UI file, so anyone updating key-value-editor (or 25 others) gets a component that imports itself.

This renames every colliding lib file to <name>-utils.ts, so there is no second file with that name for the CLI to match:

  • 27 lib files renamed, with registry.json, UI imports, previews and test imports updated. That's the 25 from #135, plus activity-heatmap from #137 and csv-importer from #150, which landed with the same pattern.
  • The .ts imports and allowImportingTsExtensions from #136 are reverted.
  • The guard test now fails if any file in registry/default/lib shares a basename with one in registry/default/ui. The old test checked the import string, which activity-heatmap passed because of the .ts suffix.
  • AGENTS.md and CONTRIBUTING.md say <name>-utils.ts for new lib files.

Users who already installed one of these components keep the old lib/<name>.ts after updating. Nothing imports it anymore, so it's harmless and they can delete it.

If you'd rather use topic names than the -utils suffix, say so and I'll rename them.

Closes #135

Checklist

  • bun run typecheck, bun run lint and bun run test pass
  • Tests cover the change, including keyboard interaction for UI components
  • New components are added to registry.json, lib/catalog.ts, components/docs/preview-registry.tsx and lib/agent-docs/component-usage.ts, each at its alphabetical position
  • Checked in light and dark mode