[feat]: Use cn instead of ny for class name helper

[bryaneaton13]

Feature description

I'm suggesting switching back to the standard cn class name helper that shadcn and magicui use for the tailwind merge utility helper. The ny function is a custom thing that's not as clear what it means.

This will help when getting AI to auto-generate code (like GitHub copilot or Cursor) using the components already in the code base. And it'll help when using tools like v0.dev to create the UI elements.

Affected component/components

All Components with styling

Additional Context

Right now, the manual installation shows using this class name helper in lib/utils.ts:

import { clsx, type ClassValue } from "clsx"
import { twMerge } from "tailwind-merge"
 
export function ny(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

I'm suggesting using this instead:

import { clsx, type ClassValue } from "clsx"
import { twMerge } from "tailwind-merge"
 
export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

Before submitting

• I've made research efforts and searched the documentation
• I've searched for existing issues and PRs

Related commits

91f664a
283b44d
a702f31
134658b
dd2ea8d
dac8517
5be2fdb

[github-actions[bot]]

Hello there 👋 Thanks for opening your first issue. We welcome you to the ui community! 😊

[lacymorrow]

Yep, as few things "custom" as possible.

[EdMaxi]

+1 for it.
IA's will work better with standards, if possible, when possible to sticky with standards of things already done previously.

[lacymorrow]

Plus, lots of folks use shadcn/ui. If you keep things standard we can use the same CLI to install components (like v0, magicui, personal registries, etc)

[RayRizzling]

Am I the only one who likes the ny ? ^^ it's helpful as I can clearly see the origin of the component when combining multiple frameworks/code snippets, like aceternity + nyxb. I run a snippet on the codebase to change the imports from import { ny } to import { cn as ny } when adding the whole lib or manually when just adding some snippets.

[nyxb]

I will keep using ny simply because it reflects the unique character and flair of the library. For Cursor, we can address the auto-generation concern by specifying custom Cursor rules. As for v0.dev compatibility, we can implement the solution mentioned in the last comment from @RayRizzling by using import { cn as ny }. This way, we maintain our distinct identity while ensuring compatibility with various tools.

The ny prefix serves as a clear indicator of component origin when combining multiple frameworks or code snippets (like aceternity + nyxb), making it easier to track the source of components in a mixed codebase. This naming convention provides value in terms of code organization and maintainability.
For those who prefer using the standard cn helper, they can easily alias it as demonstrated:

import { ny as cn } from './utils'
// or
import { cn as ny } from './utils'

This approach gives us the best of both worlds - maintaining our library's unique identity while providing flexibility for developers who prefer standard conventions.

I'll transfer this to discussions as it's more of a design philosophy discussion rather than an issue that needs to be resolved. This will allow for a more open dialogue about naming conventions and library identity.