Shadcn/UIがRadixの代わりにBase UIをデフォルトへ変更

 (ui.shadcn.com)
3 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • shadcn/uiは2026年7月から、新規プロジェクトとドキュメントのデフォルトフローをBase UI中心に変更し、2023年のリリース以来続いていたRadixデフォルトから方向転換する
  • Base UIは安定版1.6.0と週間600万回以上のダウンロードに到達し、shadcn/createプロジェクトでもRadixより2:1で多く選ばれている
  • Radixはサポート終了にならず、既存アプリはそのまま維持してよく、Base UIにしかないコンポーネントを除けばアップデートと新コンポーネントも引き続き提供される
  • マイグレーションはcodemodではなくエージェントskillとして提供され、変更済みコンポーネントと利用箇所をコンポーネント単位で段階的に移行し、.migration/レポートとgitコミットを残す
  • チャットUIコンポーネント、GitHubリポジトリベースのregistry、shadcn eject、新スタイルRheaも加わり、shadcn/uiの範囲はコンポーネント配布とプロダクトUI構成全般へ広がる

Base UIがデフォルトのコンポーネントライブラリに

  • 2026年7月からBase UIがshadcn/uiのデフォルトコンポーネントライブラリに指定される
  • shadcn/uiは2023年1月のリリース時にRadixベースで作られており、当時Radixはスタイルを持たないヘッドレスコンポーネント、API、アクセシビリティ、実際のアプリでの利用実績を備えた選択肢だった
  • Base UIはRadixを作った人たちが新たに作っているライブラリであり、shadcn/uiは既存の抽象化を維持したまま、すべてのコンポーネントをBase UI向けに作り直した
  • 2025年12月にはnpx shadcn createで両方のライブラリを選べるようにし、2026年1月にはBase UIのドキュメントを完成させた

デフォルトを変えた理由

  • Base UIの安定性と利用の流れ

    • Base UIのバージョンは1.6.0
    • 週間ダウンロード数は600万回以上
    • Base UIチームは新しく有用なコンポーネントを定期的に配布している
    • shadcn/uiの新規プロジェクトはBase UIを使用中
    • shadcn/createで生成されるプロジェクトでは、Base UIがRadixより2:1の比率で多く選ばれている
    • shadcn/uiはこの選択の流れを公式デフォルトとして反映する

新規プロジェクトとドキュメントで変わる点

  • 新規プロジェクトでnpx shadcn initを実行すると、Base UIがデフォルトの選択肢になる
  • shadcn/createはBase UIを先に表示する
  • ドキュメントのコンポーネントページはBase UIタブをデフォルトで開き、Radixのドキュメントへは1クリックでアクセスできる

Radixユーザーが知っておくべきこと

  • Radixは引き続きサポートされる

    • shadcn/uiはRadixサポートを維持する
    • Base UIにのみ存在するコンポーネントを除けば、すべてのアップデートと新コンポーネントは両ライブラリに提供される
    • 既存アプリはマイグレーションする必要がない
    • Radixは成熟し、テストされたライブラリである
    • shadcn/uiもRadixを本番環境で引き続き使用しており、自身のプロジェクトもマイグレーションしない
    • 新規プロジェクトでRadixを好む場合はフラグを使える
    • shadcn initを非対話で実行するスクリプトやCIがRadixを期待している場合は、既存の経路を維持するために-b radixを追加する必要がある
    • registryを作る際に特定のライブラリへ固定したい場合は、registry:base設定を提供できる
    • その設定がない項目は、今後Base UIで初期化される
    • 新規プロジェクトにはBase UIが推奨される

Base UIへ移行する方法

  • マイグレーションは必須ではないが、希望する場合はskillを使用できる
  • コーディングエージェントには次のように依頼できる
    • migrate accordion to base-ui
  • 基本方式は段階的マイグレーション
    • コンポーネントと利用箇所を1つずつ移行する
    • プロジェクトは常にgreen状態かつデプロイ可能な状態を維持する
    • 作業中は両ライブラリが共存する
    • 途中で止めて、後から続きに取り組める
    • 望むならプロジェクト全体を一度に依頼することもできる

codemodではなくskillを選んだ理由

  • shadcn/uiコンポーネントはユーザーが所有し変更するコードなので、codemodは手を加えていないコンポーネントには合っても、変更済みコンポーネントでは壊れる可能性がある
  • skillには名前変更、prop変更、挙動の差が両ライブラリ基準で手作業確認されて入っている
  • エージェントはユーザーが変更した部分を把握し、その変更を移行対象にも反映する
  • 機械的に処理できる変更は全体で修正される
    • 例: asChildはrenderに変わる
  • 挙動の変化は黙ってパッチされず表示され、最終判断はユーザーが行う

マイグレーションが残す成果物

  • 各実行は3つの結果を残す
    • 動作するコード: 成功報告の前に型チェックとビルドを実行する
    • コンポーネント別レポート: プロジェクトルートの.migration/に変更点、そのまま残した部分、手動確認チェックリストを残す
    • きれいなgit履歴: ブランチ上にコンポーネントごとに1つのコミットを残し、ロールバックはブランチを削除すればよい
  • レポート例は.migration/accordion.mdで、次のセクションを含む
    • Changed
    • Left alone
    • Behavior changes
    • Verify by hand
  • 隠れた状態なしに進捗がファイルとgit履歴に残るため、どのエージェントやセッションからでも作業を続けられる
  • Claude Code、Cursor、skillをサポートするエージェントで動作する
  • 実プロジェクトのテストでは60個以上のコンポーネントのうち36個がRadixで、全体のマイグレーションは約25分、コンポーネントあたり約1万トークンで進められた
  • ビルドは問題なく通り、カスタマイズも維持された

チャットインターフェース用コンポーネントを追加

  • 2026年6月には、チャットインターフェースを作るための新コンポーネントが追加された
  • 最初の段階は会話レイヤーを構成する中核部品
    • スクロール
    • メッセージ行
    • 吹き出し
    • 添付
    • マーカー
  • MessageScrollerは会話用スクロールコンテナ
    • anchored turns
    • streamed replies
    • saved thread restore
    • prepended history
    • jump-to-message
    • scroll controls
    • visibility trackingを処理する
  • MessageScrollerはメッセージ、AI状態、送信、保存、モデル状態を所有せず、コンテンツレンダラーはユーザーが提供する
  • MessageScrollerは@shadcn/reactのスタイルなしヘッドレスコンポーネントとしても提供される

Message、Bubble、Attachment、Markerの役割

  • Messageは会話の1行を配置する
    • アバター
    • 整列
    • ヘッダー
    • コンテンツ
    • フッター
    • グループメッセージを扱う
  • Bubbleはメッセージのサーフェスをレンダリングする
    • variants
    • 整列
    • reactions
    • links
    • buttons
    • collapsible contentをサポートする
  • Attachmentはファイルと画像をレンダリングする
    • media
    • metadata
    • upload state
    • actions
    • 個別にクリック可能なactionを維持するfull-card triggerを提供する
  • Markerは状態更新、システムノート、ボーダー行、ラベル区切り線をレンダリングする
    • streaming state
    • tool activity
    • date breaksのような用途に使われる
  • これらのコンポーネントは小さく設計されており、AIチャット、サポート受信箱、チームスレッド、グループチャット、プロダクト別の会話UIに組み合わせられる

チャットUI用CSSユーティリティと@shadcn/react

  • 新しいCSSユーティリティが2つ追加された
    • scroll-fade: スクロールコンテナの端にスクロール認知用のfadeを追加する
    • shimmer: "Thinking…"、"Generating response…"、ツール実行、ストリーミングマーカーのようなライブ状態テキストにshimmerを追加する
  • 2つのユーティリティはshadcn/tailwind.cssに含まれる
    • npx shadcn@latest initで初期化したプロジェクトにはすでに含まれている
  • @shadcn/reactはスタイルなしヘッドレスReactコンポーネント向けの新パッケージ
    • 最初のprimitiveは@shadcn/react/message-scroller
    • registryコンポーネントはshadcn/uiスタイルで包むが、anchoring、auto-follow、prepend preservation、scroll commands、visibilityのようなスクロール挙動はパッケージ内にある
  • この方式は視覚スタイルに縛られずに挙動を提供し、難しいインタラクションロジックを1か所でテストできるようにする
  • RadixとBase UIの両方で利用可能

AI Elementsとの関係

  • 新しいチャットコンポーネントはAI Elementsを置き換えるものではない
  • AI ElementsのAIインターフェースコンポーネントとパターンは引き続き使用できる
  • 今回のリリースは、チャットの中核部品をshadcn/uiに1つずつ取り込むことに焦点を当てている
  • すでにAI Elementsコンポーネントを使っているなら、アプリを書き直す必要はない
  • より新しい抽象化、更新されたスタイル、RadixとBase UIの両方のサポートが必要なときは、shadcn/ui版を試せる

GitHubリポジトリをregistryとして使用

  • 2026年6月から公開GitHubリポジトリをregistryとして使用できる
  • リポジトリルートにregistry.jsonを追加し、配布する項目を定義すると、ユーザーはshadcn CLIでGitHubから直接インストールできる
  • GitHub registryはsource registry
    • shadcn buildを実行する必要がない
    • 生成されたitem JSONファイルをpublishする必要がない
    • registryサーバーを設定する必要がない
  • CLIはルートのregistry.jsonを読み、include項目を解釈し、要求された項目を見つけて該当ファイルをインストールする
  • registry項目はコンポーネントに限定されない
    • components
    • hooks
    • utilities
    • design tokens
    • feature kits
    • project conventions
    • agent instructions
    • testing setup
    • CI workflows
    • release workflows
    • templates
    • codemods
    • migration kits
    • その他のプロジェクトファイルを配布できる
  • GitHub registryのアドレスは既存registryアドレスと同じコマンドで動作する
    • list
    • search
    • view
    • install

shadcn ejectとshadcn/tailwind.css

  • RadixとBase UIの両方をサポートするにあたり、2つのライブラリが依存する共有Tailwindユーティリティを置く場所が必要になった
    • 例: data-open:、data-closed:のようなcustom variant
    • 例: no-scrollbarのようなutility
  • RTLサポート作業中の一部バグも、すべてのコンポーネントに重複適用する代わりに1か所で直しやすかった
  • そのために**shadcn/tailwind.css**が作られた
    • init実行時にグローバルCSSファイルへ@import "shadcn/tailwind.css"が追加される
    • tw-animate-cssのようなCSS importとして動作する
    • 本番環境ではtree-shakenされ、ビルド時に解決される小さな依存関係
  • shadcnパッケージのCSS依存を望まない場合は**shadcn eject**を使用できる
    • shadcn/tailwind.cssをグローバルCSSファイルにinlineする
    • プロジェクトからshadcn依存を削除する
  • monorepoでは、components.jsonとグローバルCSSファイルがあるworkspaceでコマンドを実行する必要がある

新スタイルRhea

  • 2026年5月には新しいshadcn/uiスタイルRheaが追加された
  • RheaはよりcompactなLumaで、小さなspacingとより密度の高いsurfaceを持ち、focused product interface向けに作られている
  • RheaはLumaの柔らかさと形状を維持しつつ、ボタン、入力、メニュー、カード、リストをよりタイトに配置する
  • Lumaの--spacingを調整する方式は選ばなかった
    • --spacingはmultiplierなので、変更するとアプリ全体でp-2、w-4、m-16のような慣れたTailwind utilityの意味が変わってしまう
  • Rheaは別スタイルとして提供され、component size、gap、densityを直接調整しながら、underlying utility scaleは予測可能なまま維持する
  • Rheaはshadcn/createでRadixとBase UIの両方に使用できる

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Hacker News の意見

  • この記事からは Claude 特有の文体がかなりはっきり感じられて、もう少し疲れるし距離を感じる
    重要な製品リリースの記事でさえ、人がきちんと気を配る価値がないのだとしたら、どこで線を引けばいいのかわからない

    • 文章は必要な内容を効果的に伝えていたし、人が読みやすいように書かれ、構成されているように見えた
      AI で書いたことで、この優れたオープンソースソフトウェアの開発により多くの時間を使えたのなら、むしろ良いことだと思う
    • 何を言っているのか正確にわかる。Claude と plannotator をよく使っているが、特定のスタイルガイドを頼んだ後はずっと良くなった
      「CD 時代の MSDN リファレンスと Raymond Chen のブログのスタイル」を出発点のプロンプトにしたところ、AI が作った計画を消化する能力が大きく上がった。謙虚で洞察があり、読者を尊重するスタイルなので強くおすすめする
    • 読んでみたが、AI が書いたようには聞こえなかった
      チームの誰かが人間が書いたと言い出したら、ちょっと笑える気がする
    • 真面目に聞くと、なぜそれが重要なのかと思う。下書きを書いた後で Claude の文章を見直して公開したのかもしれない
      AI が仕事を手伝うたびに、なぜわざわざ「見破ろう」とするのかわからないし、これは F500 企業ではなくオープンソースプロジェクトだ。リソースも限られていて、英語が母語ではない可能性もある
    • むしろ、うんざりして聞き流すような話ではないと思う。今のような使われ方や示され方は、欺きと嘘に近いからだ
      協力の文化には信頼と真実が必要だと信じているし、AI が「私がやった／言った」と偽って語る文章は望まない
      たとえばこの記事が本当に Claude の書いたものなら、「I said」「I meant it」のように、チームの人間が直接語ったかのように装う理由は何なのか疑問だ。それはなりすましであり欺瞞的だ。協力と誠実さを守る文化なら、「私の人間が言った」とするか、少なくとも人間の代わりに行動する AI だと正しく表示すべきだ

  • 退屈なアプリケーションでは、人々が Mantine のような従来型の UI ライブラリよりも shadcn のコピー＆ペースト方式を好むのか気になる
    コピー＆ペースト方式は修正しやすいが、新たな問題も生む。単にバージョン番号を上げればよかったことに、今度はアップグレード用の AI エージェントが必要になるようなものだ

    • 「単にバージョン番号を上げればいい」という言い方は、ここ数年 Material UI が生んできた厄介さをかなり過小評価している
      退屈なアプリではなく非常に大きなアプリで、メジャーバージョン更新のたびに API を大きくひっくり返し、退屈な移行作業が必要だった。shadcn に移ってからは、単一コンポーネントだけをアップグレードし、新しいコンポーネントを自由に追加できるので楽になった。Material UI ではどこかで新機能を使うには全体を新しい API に合わせて変える必要があったが、shadcn では選択的にできる
    • コピー＆ペースト方式はまったく理解できなかった。Shadcn はただ流行の匂いがするし、実際にコピーして使ってみても何がすごいのかわからない
      それでも好きに使えばいいし、AI の利点の一つは、HN が以前ほど JavaScript フレームワークの話で埋まらなくなったことだ
    • 新しいプロジェクトでは、だんだん**ベンダリング（vendoring）**寄りになっている
      既成の UI ライブラリを取り込むのは短期的には楽だが、たいてい過度に複雑で、使わない機能まで実装されており、同じライブラリを使う大量のアプリと差別化しようとすると修正が難しく、アップグレード時にはその修正が微妙に壊れる。最善のアプローチは自分の UI ライブラリを作ることだと思う。自分で所有し、複数のプロジェクトで再利用し、望めば同じ視覚スタイルを保ち、必要な機能だけを追加できる
    • Mantine は素晴らしい。ほとんど何でも素早く作れて、その後で拡張したり、テーマや個別コンポーネントを完全にカスタマイズしたりできる
      学習曲線はあるが、巨大というほどではないと思う
    • 多くのシステムでは、実際には「単にバージョン番号を上げる」だけで済むことはほとんどない。コンポーネントライブラリが望むことを正確にしてくれる場合にだけ、それが可能だ
      実際には必要な挙動をコンポーネントが完全には提供していないことが多く、人々はコンポーネントに追加 CSS を頻繁に継ぎ足す。代替案が数時間の作業なら、CSS を2行足すのは非常に魅力的だが、その2行もコンポーネントライブラリの新機能ごとに検証しなければならない。こうした CSS の継ぎはぎが増えると、アップグレードは一つのプロジェクトになる

  • こういう人気 UI ツールキットが div を過剰にレンダリングするのが気になる
    Base UI を見ると、ほぼすべてのコンポーネントが「要素をレンダリングする」という感じだが、アコーディオンには details/summary のように同じことができるネイティブ要素がある。ネイティブ Web の伝道師ではないし、Web API、とくに HTML にも問題は多いと思っているが、div の乱用も間違っている

  • Shadcn を使ったことがあり、概ね気に入っているが、Radix ベースのラジオボタンは少しやりすぎだった。同じように過度に膨らんだ解決策が使われている選択肢もある
    https://news.ycombinator.com/item?id=46688971

  • マイグレーション作業が codemod から LLM へ移っていく流れが興味深い
    codemod のほうがより決定的ではあるものの、その時代が終わりつつあるのか気になる

    • LLM を活用して 決定的な codemod を作るのはどうだろうと思う
      そのうえで codemod を実行し、ほかの決定的な安全策を付けて反復しながら、結果を再び LLM に入れて codemod を改善できる
    • 原文記事のフレーミングは危険な考え方だ。codemod 自体はあってもなくてもよい
      欲しいのは LLM 用の skill ファイルではなく、人間のためのドキュメントであるべきだ。人間向けの マイグレーションガイド を書けばよい。結局、skill ファイルとドキュメントは同じものであるべきだと気づくまでには、少し時間がかかるだろう
    • ここで codemod が何を意味しているのか気になる
    • 両者は完全に補完し合うと思うし、今後もそうだろう
      柔らかいルールには AGENTS.md ファイルを使い続け、強いルールにはカスタム linter ルールを使っているが、これが両方の世界の長所を取り入れるやり方だと思う

  • shad-CN を使いたいが、毎回結局 Mantine に戻ってしまう
    どのコンテキストをつなぐべきか覚えているより、ずっと速い

  • この変更がユーザーに バンドルサイズ削減 のようなより良い結果をもたらすのか気になる
    それとも Shadcn メンテナーの生活の質を上げる変更に近いのだろうか

  • Angular における shadcn/ui に相当するもの は何なのか気になる
    PrimeNG が最近ライセンスを変更したため、新規プロジェクトに合う代替を探している

    • PrimeNG のライセンス変更を HN に載せようとした 2 回の試み[1]は失敗したが、PrimeTek のコンポーネントライブラリを使っているなら、この変更は知っておくべきだ
      PrimeNG、PrimeReact、PrimeVue はすべて完全なクローズドソースへ移行し、2027 年から継続利用ライセンスは開発者シートあたり 800 ドル になる[2]。既存のリポジトリはアーカイブされる[3]。PrimeFaces は引き続きオープンソースだが、今後は PrimeTek の社員ではない独立したボランティア開発者たちが開発・保守する
      [1]: https://hn.algolia.com/?q=The+Next+Chapter+of+PrimeTek
      [2]: https://primeui.dev/nextchapter
      [3]: https://github.com/primefaces/primeng
    • 同じ状況だ。職場で複数のアプリに PrimeNG を使ってきており、適切な代替が見つかるまでは Angular 21 に縛られることになりそうだ
      ただ、あるグループが PrimeNG をフォークしており、保守する計画だという。新しい名前はまだ未定だ
      https://github.com/openng-org/open-prime
    • https://spartan.ng/
    • Shadcn に似たシステムが Svelte、Angular、Nunchucks のような複数のスタックで直接使える形ではまだ提供されていないことへの対応として、Lily Design System を作っている
      すべて無料のオープンソースで、フィードバックや提案を送ってくれれば Lily に簡単に追加できる
      https://lilydesignsystem.github.io
    • https://www.zardui.com

  • 昔ながらの スキューモーフィックなスタイルガイド が恋しい
    最後は Blueprint だった気がする

  • URL は https://ui.shadcn.com/docs/changelog/2026-07-base-ui-default であるべきだ