Recommended pattern for customizing Button sizes without affecting Calendar?

[dev-fatih-erol]

Hi,

I’m trying to customize the default Button height in my project.

For example, I want my app buttons to use a different size scale like:

sm: "h-9 px-3"
default: "h-10 px-4"
lg: "h-11 px-5"

But I noticed that some shadcn components depend on Button / buttonVariants.
For example, in the Calendar component: import { Button, buttonVariants } from "@/components/ui/button"

The previous / next navigation buttons use: buttonVariants({ variant: buttonVariant })

and the day button uses: <Button variant="ghost" size="icon" />

So if I customize shared Button styles such as:

size.icon
variant.ghost
base focus/ring classes
transition/border classes

Calendar can also be affected.

Is this dependency intended?

What is the recommended design-system approach here?

Should I:

Keep the original shadcn Button variants/sizes stable and add app-specific sizes like app, appSm, appLg?
Create a separate AppButton component for product UI and keep shadcn Button only for internal shadcn components?
Detach components like Calendar from buttonVariants and give them their own internal styles?

I’m not asking how to patch Calendar specifically.

I’m trying to understand the recommended pattern for customizing Button sizes safely without having to manually check every component that might depend on buttonVariants.

Thanks.

[mg1986jp]

The issue is that Calendar (and other components) import buttonVariants and use specific size variants internally. If you change the default sizes in your Button, Calendar's styling breaks because it's expecting the original values.

The cleanest approach is to not modify the existing size variants, but add new custom ones instead. Keep sm, default, lg as shadcn defined them, and add your own like app-sm, app-default, app-lg with your preferred sizes. Use the custom variants in your app code, and the internal components keep working with the originals.

If you really want to override the defaults, you'd need to also update every component that uses buttonVariants with explicit size overrides. Calendar uses size="sm" for the day cells and navigation buttons, so you'd pin those to your old values. It's doable but fragile — every time you update shadcn components, you'd need to re-apply those fixes.

[DaCameraGirl]

The dependency is intentional by design — internal components like Calendar use buttonVariants so they inherit consistent styling. Here's the recommended approach to customize sizes without breaking anything.

Recommended Pattern: Add custom size variants, don't override defaults

In your button.tsx, extend the size variants with your own named sizes alongside the originals:

// components/ui/button.tsx
const buttonVariants = cva(
  'inline-flex items-center justify-center ...',
  {
    variants: {
      variant: {
        default: '...',
        // ...other variants
      },
      size: {
        // Keep ALL original sizes intact for internal components
        default: 'h-10 px-4 py-2',
        sm: 'h-9 rounded-md px-3',
        lg: 'h-11 rounded-md px-8',
        icon: 'h-10 w-10',

        // Add YOUR custom sizes with different names
        'app-default': 'h-10 px-4',
        'app-sm': 'h-9 px-3',
        'app-lg': 'h-11 px-5',
      },
    },
    defaultVariants: {
      variant: 'default',
      size: 'default', // Calendar uses this default, leave it alone
    },
  }
);

Then use your custom variants in your app code:

// App buttons use your custom sizes
<Button size="app-default">Click me</Button>
<Button size="app-sm">Small</Button>

// Calendar still uses default/sm/icon internally — untouched
<Calendar />

Alternative: Wrap Calendar with its own Button override

If you truly want to change what default and sm mean globally but protect Calendar, wrap Calendar in a CSS layer:

// components/calendar-wrapper.tsx
export function CalendarWrapper(props: React.ComponentProps<typeof Calendar>) {
  return (
    <div className="[&_.rdp-button]:h-9 [&_.rdp-button]:w-9 [&_.rdp-nav_button]:h-7 [&_.rdp-nav_button]:w-7">
      <Calendar {...props} />
    </div>
  );
}

This uses Tailwind's arbitrary variant selector to pin Calendar's internal button dimensions regardless of what buttonVariants resolves to globally.

Why this happens

The shadcn philosophy is that you own the component code — they're not a library you upgrade. So the recommended approach is: add to buttonVariants, don't change the values that internal components depend on. The Calendar, Combobox, and other composite components rely on known size values to maintain their own internal proportions. Changing sm globally to h-9 px-3 instead of the original may shift layouts in unexpected ways throughout those components.

[Adit-Jain-srm]

The recommended pattern is to create a separate set of size variants for your app buttons while keeping the internal buttonVariants untouched for shadcn component internals.

Option 1: Create an AppButton wrapper (cleanest)

// components/ui/app-button.tsx
import { Button, type ButtonProps } from '@/components/ui/button'
import { cn } from '@/lib/utils'
import { cva } from 'class-variance-authority'

const appButtonSizes = cva('', {
  variants: {
    size: {
      sm: 'h-9 px-3',
      default: 'h-10 px-4',
      lg: 'h-11 px-5',
    },
  },
  defaultVariants: { size: 'default' },
})

export function AppButton({ size, className, ...props }: ButtonProps) {
  return (
    <Button
      {...props}
      size={null} // disable default sizing
      className={cn(appButtonSizes({ size }), className)}
    />
  }
}

Option 2: Override at the CSS layer using Tailwind

In your globals.css, override the internal button heights for Calendar specifically:

[data-slot='calendar'] button {
  @apply h-7 w-7; /* keep calendar nav buttons small */
}

Why not just edit buttonVariants directly?

You can, but every shadcn update will conflict, and components like Calendar, DatePicker, Pagination all assume the default sizes. Keeping a separate AppButton gives you full control without breaking internals.

@dev-fatih-erol The wrapper approach is what most production shadcn projects use — it gives you a clean separation between your app's design system and shadcn's internal component composition.

[dev-fatih-erol]

Thanks @Adit-Jain-srm , this was exactly what I was looking for.

I went with the AppButton wrapper approach and kept the original shadcn Button variants untouched. This gives me control over my application button sizes without unintentionally affecting internal components like Calendar.

Appreciate the clear explanation!