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.

By shadcn-ui · 14,012 installs

npx skills add shadcn-ui/ui --skill migrate-radix-to-base

Source repository · Upstream listing

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) 1. 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. 2. 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. 3. Require a clean git tree; work on a branch; one commit per component. 4. Baseline check BEFORE touching dependencies: run the project's typecheck/build so pre existing failures are never attributed to you. 5. Install @base ui/react alongside 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: 1. 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. 2. WHOLE PROJECT mode: flip components.json style radix <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 ). 3. PRISTINE wrappers, whole project mode: shadcn add <component overwrite delivers 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.tsx instead. 4. CUSTOMIZED wrappers: fetch the base variant and replay the user's diff onto it (their customizations must SURVIVE; overwrite would 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. 5. 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 against consumer props.md . 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 <style variant would restyle the user's app. Use the radix golden ONLY to detect customizations, then run the transformation engine on the user's OWN file: rewire primitives, keep their exact classes, apply class mapping renames. Their look stays theirs. At the end of a legacy whole project migration, FLAG (do not fix): the style name still reads as radix to the CLI, so future shadcn add will deliver radix variants; the user decides whether to switch style or add manually. Transformation engine (fallback). Hand rolled radix code, non shadcn projects, unknown styles: transform using universal patterns.md (imports in BOTH forms: radix ui and @radix ui/react ; asChild render with the worked example; Portal Positioner Popup; the positioner FORWARD rule; part renames), the per family props tables ( overlays.md , menus.md , form controls.md , disclosure.md , display misc.md ), class mapping.md for data attribute/CSS var rewrites, and wrapper shapes.md for exact target shapes (tooltip arrow, SubContent defaults, select anatomy). Modes Progressive (default). "Migrate accordion" = one component, strangler fig: 1. Detect in progress state first: an existing <component base.tsx , consumers split between old/new imports. The files ARE the state; resume, never restart. 2. If the component imports other ui wrappers still on radix (select button), STOP and recommend migrating those first, bottom up. 3. Write the migrated version to <component base.tsx (original untouched; golden pair content fetched by URL, or transformed by hand, per the strategy above); typecheck. Repoint consumers ONE AT A TIME (imports + the call site props in consumer props.md ); typecheck each. When no consumer imports the original: delete it, rename base original, flip imports back, final check, commit. When the LAST radix wrapper in the project is finalized, flip components.json to base <style and remove radix deps. Whole project (only when explicitly asked): same per component work in dependency order (leaf/shared wrappers like button and label first). After wrappers, sweep ALL app code against consumer props.md — the call site break surface is much larger than asChild. Then remove radix deps, install, full build. Hard rules NEVER touch non radix libraries or their wrappers: cmdk (command), vaul (drawer), sonner, input otp, react day picker (calendar), recharts (chart). Report them as intentionally untouched. No Base UI counterpart: AspectRatio CSS aspect ratio div; Label native <label ; VisuallyHidden sr only ; Direction Direction Provider ( direction prop, not dir ). Popover Anchor and NavigationMenu Indicator have no equivalent: inert passthrough + flag. button.tsx migrates to the REAL @base ui/react/button primitive, never a hand rolled useRender wrapper. Behavior deltas are FLAGGED, never silently patched (tabs manual activation, menu items not closing on click, nav menu 50ms delay). The target is idiomatic Base UI matching the shadcn base registry. Honest reporting: skipped/reverted files are listed as flagged, never as migrated. Pre existing failures are named as pre existing. Verify and report Typecheck per file, build per batch, full build at the end vs the baseline. 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 ui alias 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):