How to move radix-ui to base-ui?

[indramal]

How to shift radix-ui to base-ui in my current project?

Do I need to manually change every components?

npx shadcn@latest add ___ How this command know it is radix or base? Where do i need to change to get that command it use base-ui?

[jaem0629]

Unfortunately, there's no automatic tool for that.

If it's because of Combobox, you could either start a fresh project with Base UI and migrate your code, or just grab the Combobox code from combobox.tsx, install dependencies manually, and see if it works.

[indramal]

npx shadcn@latest add ___ How this command know it is radix or base? Where do i need to change to get that command it use base-ui?

[jaem0629]

@indramal You can change the style in components.json to base-vega

{
        ...
        "style": "base-vega",
        ...
}

Then npx shadcn@latest add { component } will install the Base UI version

[jaem0629]

I think combobox might work with base-vega, try npx shadcn@latest add combobox

[indramal]

Thanks

[Macho006]

Migrating from Radix UI to Base UI is a significant change because they are two different primitive libraries with different APIs and styling approaches. Here is the breakdown of your questions:

1. Can it be done automatically?
   Currently, there is no official automated script to swap Radix for Base UI across an entire project. Since the component props and internal structures differ, you will likely need to update your components manually or by using a carefully crafted "Find and Replace" (though manual review is safer).

2. How does npx shadcn@latest add work?
   The shadcn CLI doesn't automatically "know" which primitive you prefer unless it's specified in your configuration.

Current State: By default, Shadcn has been built on top of Radix UI.

The Shift: Shadcn recently introduced support for Base UI. To use Base UI components, you usually need to initialize or update your components.json to point to the Base UI compatible registry.

3. How to use the command for Base UI?
   If you want the CLI to pull Base UI versions, you typically need to specify the registry or use the experimental versions if available. However, for an existing project:

Update components.json: You need to ensure your configuration allows for different primitives.

Manual replacement: Even if you run the command to add a new Base UI component, it will create a new file in your components folder. It won't automatically rewrite your existing Radix-based components.

Advice: If your project is large, I recommend migrating component by component rather than all at once. Start by adding the Base UI version of a component: npx shadcn@latest add [component-name] --base (Note: Check the latest Shadcn documentation as the flags for Base UI are being finalized).

[indramal]

Are the props the same for all Shadcn Base UI and Shadcn Radix UI components? Then my codes not breaks

[Macho006]

Unfortunately, no, the props are not identical. While Shadcn tries to keep the high-level API similar for consistency, the underlying primitives (Radix UI vs. Base UI) have different naming conventions and internal logic.

Why your code might break:
Prop Naming: Radix often uses specific prefixes or names for state props (e.g., onOpenChange), while Base UI might use different naming conventions (e.g., open and onChange).

Component Structure: The way components are nested can differ. For example, a DropdownMenu in Radix might have a slightly different internal tree compared to Base UI.

CSS Classes: Since the internal structure changes, your custom Tailwind classes (especially those targeting data-attributes like data-state="open") might need adjustments because Base UI uses different state attributes.

My recommendation to avoid breaking your site:
Don't "Find and Replace": Do not simply swap the import names globally.

Side-by-Side Migration: Install the Base UI version of a component as a new file (e.g., button-new.tsx), test it in one place, and only then replace the old one.

Check the Docs: Always keep the Base UI documentation and Shadcn UI docs open to compare the specific props for each component you migrate.

Summary: Your code will likely break if you just swap them without checking the props. It's safer to migrate slowly, one component at a time.