shadcn/ui hat von Radix auf Base UI gewechselt

Wenn deine shadcn/ui-App auf Radix läuft, musst du nicht migrieren. Base UI ist jetzt der Standard für neue Projekte, aber Radix wird weiterhin vollständig unterstützt, Updates erscheinen für beide Bibliotheken, und das shadcn-Team setzt in seinen eigenen Produktions-Apps nach wie vor Radix ein.

Der Wechsel erfolgte am 3. Juli 2026. Die Berichterstattung seither hat vielfach den Eindruck erzeugt, ein Rewrite stünde bevor – das steht so aber nicht im Changelog.

Zwei Fragen entscheiden über das weitere Vorgehen: Musst du überhaupt handeln, und was kostet eine Migration, wenn du dich dafür entscheidest? Die Kosten teilen sich in Änderungen, die der Compiler abfängt, und solche, die er nicht abfängt – und genau bei den zweiten liegt das Risiko.

Was sich am 3. Juli 2026 geändert hat

Neue shadcn/ui-Projekte verwenden jetzt standardmäßig Base UI – an bestehenden Projekten hat sich sonst nichts geändert. Drei Dinge sind neu: npx shadcn init wählt Base UI, sofern du nichts anderes angibst, shadcn/create führt Base UI an erster Stelle seiner Liste, und die Komponentendokumentation öffnet sich nun auf dem Base-UI-Tab, mit einem Radix-Tab direkt daneben. Radix selbst ist nicht deprecated.

Um Radix in einem neuen Projekt beizubehalten, genügt ein Flag:

pnpm dlx shadcn init -b radix

Überall dort, wo CI oder ein Scaffolding-Skript shadcn init ohne Prompt aufruft und davon ausgeht, Radix zu erhalten, solltest du dieses Flag jetzt setzen. Der zugrunde liegende Standard hat sich geändert.

Musst du auf die shadcn-Base-UI-Komponenten migrieren?

Nein. Der Changelog verpflichtet sich, jedes Update und jede neue Komponente für beide Bibliotheken auszuliefern – die einzige Ausnahme sind Komponenten, die es in Base UI gibt und für die kein Radix-Gegenstück existiert. Dort steht außerdem, dass der Produktionscode des Teams selbst weiterhin auf Radix läuft, ohne Umstellungspläne. Eine stabile Radix-App hat keinen erzwungenen Zeitplan, kein Deprecation-Fenster und keine Wartungsklippe. Der restliche Artikel richtet sich an Teams, die sich für einen Wechsel entscheiden – nicht an Teams, die wechseln müssen.

Warum wurde der Standard umgestellt?

Der Changelog nennt vier Gründe. Die Bibliothek hatte mit 1.6.0 einen stabilen Stand erreicht und überschritt sechs Millionen Downloads pro Woche. Ihre Maintainer ergänzen laufend nützliche Primitives. Das shadcn-Team hatte sich für alles Neue ohnehin schon darauf standardisiert. Und unter denjenigen, die Projekte mit shadcn/create aufsetzen, gewann Base UI etwa zwei Entscheidungen auf jede, die an Radix ging.

Diese Zahlen stammen aus dem Changelog. Base UI liefert seither weiter: 1.8.0 erschien am 4. September 2026. Der Changelog weist außerdem darauf hin, dass Base UI von denselben Leuten stammt, die Radix entwickelt haben. Das zu installierende Paket ist @base-ui/react; der ältere Name @base-ui-components/react trägt auf npm einen Deprecation-Hinweis mit Weiterleitung darauf.

Was eine Migration tatsächlich verändert

Die Build-brechende Hälfte einer Migration ist mechanisch: Umbenennungen und Typänderungen, die der Compiler sofort erkennt.

Eine Feinheit: Die Aufteilung in Positioner/Popup betrifft verankerte Popups wie Menu, Select, Popover und Tooltip. Dialog hat keinen Positioner; dort gilt Dialog.Backdrop plus Dialog.Popup.

Die Callback-Änderung sieht so aus:

// Radix: block closing via the event
onEscapeKeyDown={(event) => event.preventDefault()}

// Base UI: one callback, with a reason and a cancel()
onOpenChange={(open, details) => {
  if (details.reason === "escape-key") {
    details.cancel()
    return
  }
  setOpen(open)
}}

Auch Werttypen verschieben sich. Ein kontrolliertes Select liefert jetzt Value | null statt eines Strings – das ist der häufigste Build-Bruch:

const [fruit, setFruit] = useState<string | null>(null)

Die Werte von Accordion und Toggle Group sind immer Arrays, selbst im Einzelauswahl-Modus – aus value="a" wird also value={["a"]}.

Die Änderungen, die kompilieren, sich aber anders verhalten

Die gefährliche Hälfte der Migration besteht Type-Checks fehlerfrei und verändert das Laufzeitverhalten trotzdem. Drei Abweichungen stechen hervor:

• Tabs werden standardmäßig manuell aktiviert. Pfeiltasten verschieben den Fokus zwischen Triggern, ohne das sichtbare Panel zu wechseln – es sei denn, du setzt activateOnFocus an Tabs.List, was standardmäßig false ist. Radix aktivierte standardmäßig automatisch.
• Checkbox- und Radio-Items im Menü halten das Menü offen. closeOnClick ist bei Menu.CheckboxItem und Menu.RadioItem standardmäßig false – das Gegenteil von Radix’ Close-on-Select. Ein einfaches Menu.Item bleibt standardmäßig bei true, das Verhalten unterscheidet sich also je nach Item-Typ.
• NavigationMenu öffnet sich beim Hovern schneller. Base UIs delay liegt standardmäßig bei 50 ms; Radix’ delayDuration bei 200 ms. Menüs, an denen Nutzer früher vorbeigestrichen sind, öffnen sich jetzt.

Nichts davon erzeugt einen Fehler. Ein Menü, das nach einem Klick offen bleibt, und Tabs, die Pfeiltasten ignorieren, sind für das Error-Monitoring unsichtbar, weil nichts geworfen wird. Session Replay ist der Ort, an dem diese Klasse von Regressionen sichtbar wird: Du siehst, wie ein Nutzer eine Pfeiltaste drückt oder ein Checkbox-Item zweimal anklickt – und wie die UI nicht so reagiert, wie er es erwartet.

Wer sollte auf Base UI wechseln und wer nicht?

Migriere, wenn du Combobox, Autocomplete oder Number Field brauchst, die Radix nie geliefert hat, oder wenn du mit neuen Registry-Komponenten Schritt halten willst, sobald sie erscheinen. Bleib bei Radix, wenn deine App stabil ist und nichts davon zutrifft; die Support-Zusage ist explizit, und eine funktionierende Produktions-App gewinnt durch einen Primitive-Tausch nichts.

Triff die Entscheidung nicht auf Basis kolportierter Komponentenlücken. Base UI liefert Context Menu, Toast und ein Hover-Card-Primitive unter dem Namen Preview Card – und shadcns Base-UI-Doku deckt alle drei ab.

Wie du migrierst, wenn du es tust

Verwende den offiziellen Skill, keinen Codemod, und gehe schrittweise vor. Die Begründung überzeugt: Ein Codemod kennt nur die Standardversion einer Datei, kommt also mit den Komponenten zurecht, die du unangetastet gelassen hast, und scheitert an denen, die du geändert hast. Der Skill liest, was tatsächlich vorhanden ist, überträgt deine Anpassungen und weist auf Verhaltensunterschiede hin, statt sie stillschweigend umzuschreiben.

pnpm dlx skills add shadcn/ui

Anschließend bittest du deinen Coding-Agent, eine Komponente zu migrieren, zum Beispiel migrate accordion to base-ui. Du kannst beide Bibliotheken gleichzeitig installiert lassen, sodass der Build zwischen den Schritten grün bleibt. Jeder Durchlauf typprüft sein Ergebnis, schreibt eine Notiz zu der betreffenden Komponente in einen .migration/-Ordner und legt sie als eigenen Commit auf einem Branch ab, den du verwerfen kannst. Beginne mit Blatt-Komponenten wie Button und Label, bevor du die Komponenten angehst, die sie importieren, und lies vor dem Merge in jedem Report den Abschnitt zu Verhaltensänderungen.

Eine Warnung: Manche Anleitungen empfehlen, components.json auf Base UI umzustellen und jede Komponente mit --overwrite neu hinzuzufügen. Das verwirft jede lokale Anpassung, die du an diesen Dateien vorgenommen hast – genau das Szenario, dessen Vermeidung der Skill dient.

Was das für dich bedeutet

Der Standard hat sich geändert, deine Verpflichtungen nicht. Bestehende Radix-Apps laufen weiter, neue Projekte erhalten Base UI, sofern du nicht -b radix übergibst, und eine Migration ist ein Opt-in-Projekt, dessen sichtbare Kosten Umbenennungen sind und dessen verborgene Kosten im Verhalten liegen. Wenn du migrierst, plane QA-Zeit für die stillen Abweichungen ein – denn dort hört die Hilfe des Compilers auf. Lies zunächst selbst den Changelog-Eintrag und entscheide dann, ob Combobox oder die Ausrichtung an der Registry den Branch wert sind.

FAQs

Ist Base UI im Vergleich zu Radix produktionsreif?

Ja. Base UI hat im Dezember 2025 eine stabile Version 1.0.0 unter dem Paket '@base-ui/react' veröffentlicht und seither kontinuierlich ausgeliefert – am 4. September 2026 bis Version 1.8.0. Es stammt von den Machern von Radix, Floating UI und Material UI, und laut Team wurde die API bewusst an Radix angelehnt, damit der Wechsel zwischen beiden weniger Aufwand bedeutet. Das shadcn-Team nutzt Base UI außerdem für jedes neue Projekt, das es startet.

Sind in Base UI alle Wert-Props Arrays?

Nein. Der 'value' von Accordion ist immer ein Array und der 'value' von Toggle Group immer ein String-Array, selbst im Einzelauswahl-Modus. Der 'value' von Tabs bleibt jedoch ein einzelner Wert mit dem Standardwert 0, und Select ist als einzelner Wert, Array oder null typisiert. Verpacke also Accordion- und Toggle-Group-Werte in Arrays, typisiere kontrollierten Select-State als nullable und lass Tabs unverändert.

Betrifft eine Migration auf Base UI shadcn-Komponenten, die Radix nie genutzt haben?

Nein. Command basiert auf cmdk, Sonner ist eine eigenständige Toast-Bibliothek, Calendar nutzt react-day-picker, Input OTP nutzt input-otp, und Charts bauen auf recharts auf. Keine davon hängt von Radix-Primitives ab, eine Migration von Radix zu Base UI lässt sie also unberührt. Nur Komponenten, deren Primitives von Radix kamen – etwa Dialog, Menu, Select, Tabs und Popover – benötigen Änderungen.

Setzt der shadcn-Migrations-Skill pnpm voraus?

Nein. Der Changelog dokumentiert die Skill-Installation für pnpm, npm, yarn und bun, 'npx skills add shadcn/ui' ist also ein gültiges npm-basiertes Äquivalent zum pnpm-Befehl. Nach der Installation läuft der Skill über deinen Coding-Agent, der jeweils eine Komponente migriert und – unabhängig vom Paketmanager – typgeprüften Code, einen Report pro Komponente im Verzeichnis '.migration' sowie einen Commit pro Komponente erzeugt.