Magic UIは、Framer Motion(motion)とTailwind CSSで作られたアニメーション付きUIコンポーネント集です。shadcn/uiと同じ「コピー&ペースト」方式で、npx shadcnコマンド経由でNext.jsプロジェクトに直接コンポーネントを追加できます。ランディングページやマーケティング用UIに使うBento Grid、Globe、Terminalなどの見た目重視の部品が中心です。
配布の仕組みはnpmパッケージではなくregistry.jsonベースです。apps/www/scripts/build-registry.mtsでregistryを構築し、shadcn CLIの`npx shadcn add @magicui/globe`コマンドがpublic/r配下に生成されたJSONを取得して、ソースコード自体をユーザーのcomponents/ui/にコピーします。README通りshadcn/uiの`init`コマンドでプロジェクトをセットアップした後、必要なコンポーネントだけをその都度追加する流れです。apps/wwwはNext.js 15とfumadocs-mdxで作られたドキュメントサイト兼デモ環境で、実際のコンポーネントプレビューはcomponent-preview.tsx・component-preview-tabs.tsxが担っています。依存関係にはmotion、radix-ui各種、canvas-confetti、cobe(Globe用)、rough-notationなど視覚効果系ライブラリが並び、これらがコンポーネントの内部実装で使われる想定です。CI側はcode-check.ymlでlint・typecheck・format・registry-deps:checkを走らせ、registryとコード内の依存記述がずれていないかをスクリプトで機械的に検証しています。
- STEP 01
`npx shadcn@latest init`を実行すると、既存のshadcn/ui設定と同じ質問(スタイル・ベースカラー・エイリアスなど)に答える画面が表示されます。
- STEP 02
`npx shadcn@latest add @magicui/globe`のようにコンポーネント名を指定すると、対応するregistryのJSONが取得され、components/ui/globe.tsxとしてファイルが生成されます。
- STEP 03
生成されたコードをそのまま`import { Globe } from "@/components/ui/globe"`でページに読み込むと、cobeライブラリを使った3D地球儀アニメーションがそのまま動きます。
- STEP 04
コンポーネントによってはmotion(旧framer-motion)やcanvas-confetti、rough-notationなど個別のnpmパッケージが追加で必要になるため、依存関係が入っていないとimportエラーになる場合があります。
- STEP 05
公式ドキュメントサイト(magicui.design/docs)のComponentsListページを見ると、各コンポーネントの実際の動作プレビューとソースコードタブが並んでおり、コピー前に挙動を確認できます。
手元には「動くコンポーネントのソースコード一式」が残ります。npmパッケージとして依存追加するのではなく、TailwindクラスとReactコードが自分のプロジェクトファイルとして直接入るため、あとから自由に改造・拡張できる状態になります。ランディングページ向けの装飾的なUI(グリッド、テキストアニメーション、地球儀、ターミナル風表示など)を、ゼロから実装せずに組み込める点が実利です。
配布形態がnpmパッケージではなくregistry経由のコード生成なので、shadcn CLIのバージョンやNext.js・Tailwind v4など前提環境が揃っていないと、`shadcn add`のセットアップ段階でつまずく可能性があります。
コンポーネントごとにmotion、cobe、canvas-confettiなど個別ライブラリへの依存があり、追加したコンポーネントの数だけpackage.jsonの依存が増えていく点は把握しておく必要があります。
本リポジトリのapps/www自体はドキュメント・ブログ・マーケティングサイトのコードが大部分を占めており、コンポーネント本体のソースはregistry配下(今回のファイルツリーには含まれていない部分)にある前提で判断しています。
Next.js＋Tailwind＋shadcn/uiをすでに使っていて、ランディングページに視覚的なアクセントを素早く追加したいチームには向いています。コピー&ペースト方式なのでコードの中身を読んで調整する前提の人向けで、ブラックボックスなパッケージ導入を好む人には合わないかもしれません。この判断はREADME・package.json・installationドキュメント・CIワークフローという一次資料に基づいており、配布方式や依存構成は実際に一致していますが、個々のコンポーネントの見た目や品質そのものは今回参照したファイル群には含まれていないため、そこは実際にpreviewページを見て確認するのが安全です。