migrate-radix-to-base
Migrates React projects and components from Radix UI to Base UI. Use when asked to migrate from radix, move to base-ui, convert radix primitives, or switch a shadcn project's base library. Handles single components ("migrate accordion") and whole projects.
- 29,951
- installs
- 0 up / 0 down, score 0.00
- votes
- In the catalog since
- 30 Sept 2026
- From
- shadcn-ui/ui
Skill instructions
Rendered from the published SKILL.md, 169 lines.
Radix UI -> Base UI migration
You migrate shadcn wrappers, hand-rolled radix compositions, and their
consumers to @base-ui/react, keeping the project buildable at every step.
Be precise; never guess a mapping. When a prop or part is not in these
reference files, check node_modules/@base-ui/react/**/*.d.ts before
transforming, and record gaps in the report.
Preflight (always)
npx shadcn@latest info --json(or the project's runner): gives the current base, STYLE (e.g.radix-lyra), tailwind version, aliases, installed components, and package manager. Trust it over inference.- Detect the package manager (packageManager field / lockfile: pnpm-lock.yaml, bun.lock, yarn.lock, package-lock.json) and use IT for every install. Never leave a stale lockfile.
- Require a clean git tree; work on a branch; one commit per component.
- Baseline check BEFORE touching dependencies: run the project's typecheck/build so pre-existing failures are never attributed to you.
- Install
@base-ui/reactalongside radix. Radix packages are removed only after the LAST component is migrated (both coexist fine).
Strategy: golden pair first, transformation engine second
- Golden pair via the CLI (preferred). If the project is shadcn with a
known style (
radix-<style>), the shadcn CLI itself is the golden-pair executor:- Classify each ui wrapper FIRST: diff the user's file against its stock
origin, using the components.json style VERBATIM in the URL
(
https://ui.shadcn.com/r/styles/<style>/<component>.json, files[0].content). This works for prefixed styles (radix-nova) AND legacy unprefixed ones (new-york, new-york-v4, default), which are all still served. - WHOLE-PROJECT mode: flip
components.jsonstyleradix-<style>->base-<style>now. PROGRESSIVE mode: do NOT flip yet (the project is still mostly radix; the flip happens once, after the last component); fetch base variants directly by URL instead (https://ui.shadcn.com/r/styles/base-<style>/<component>.json). - PRISTINE wrappers, whole-project mode:
shadcn add <component> --overwritedelivers the base variant with the project's exact icon/font/preset resolution. Never bulk--all --overwrite; go component by component, or you drown in unrelated registry version drift. PROGRESSIVE mode: never use--overwrite(it destroys the original that consumers still import); write the fetched base variant content to<component>-base.tsxinstead. - CUSTOMIZED wrappers: fetch the base variant and replay the user's diff
onto it (their customizations must SURVIVE;
--overwritewould destroy them). Mechanical implementation that works at scale:git merge-file user.tsx radix-golden.tsx base-golden.tsx(three-way merge, radix golden as ancestor) auto-resolves most files; hand-resolve conflicts with the reference tables. - MANDATORY leftover sweep on EVERY golden-pair file, including ones that
merged "clean":
grep -n "radix-ui\|@radix-ui\|IconPlaceholder"per file. The registry sometimes reorders functions between variants, which makes three-way merges report zero conflicts while leaving stale radix hunks in place. A clean merge is NOT proof of a clean file. This is more reliable than reconstructing transforms; use it whenever the pair exists. Consumer/app code has no CLI mechanism: always hand-migrate it againstconsumer-props.md.
- Classify each ui wrapper FIRST: diff the user's file against its stock
origin, using the components.json style VERBATIM in the URL
(
- Legacy styles (new-york, new-york-v4, default): classification only, no replay. These have no base counterpart (there is no base-new-york), and retargeting onto a base-
Show the whole skill (49 more lines)
Reports live in a .migration/ directory at the project root, ONE FILE PER
COMPONENT: .migration/<component>.md (e.g. .migration/accordion.md).
Rules:
- Each run writes (or fully overwrites) the file for each component it migrated. Re-running a component replaces its report; never touch other components' files.
- A multi-component run ("migrate alert-dialog and dropdown-menu") writes one file per component, each self-contained; shared consumer-sweep notes are repeated in every affected file.
- Whole-project mode writes the per-component files plus
.migration/project.md(dependency swap, app-code sweep summary, final build result). - There is NO index file. Migration status is derived from disk, not
maintained: scan the project's ui directory (the
uialias from shadcn info, e.g. components/ui or src/components/ui) for remaining radix imports when asked "what's left". End every run's summary with that derived count ("N wrappers remain on Radix").
Each .migration/<component>.md uses EXACTLY this structure (it is
documented publicly; reports must match it):
# <component>
<date, strategy used (golden pair via CLI / merge / engine), one-line verdict>
## Changed
<every file touched, with what changed and why; include file:line for
anything notable. Confirm the leftover scan is clean:
grep -n "radix-ui\|@radix-ui" on this component's files>
## Left alone
<files that look related but were intentionally not touched, with the reason
(cmdk/vaul/sonner are not radix; unrelated drift; etc.)>
## Behavior changes
<differences that compile fine but act differently; flagged, never patched
(tabs activation, menu close-on-click, delays...). Empty section if none>
## Verify by hand
<short manual QA checklist for this primitive family: focus return on
dialogs, keyboard nav + typeahead on menus/select, tooltip delay feel,
slider commit events. Concrete steps, one minute of clicking>