フレームワーク（オープンソースソフトウェア）。Expoの公式サンプルプロジェクト集です。expo/examplesリポジトリには、約70個の「with-*」統合例（Stripe、Clerk、Supabase、OpenAI、地図、Reanimated、SQLite、Skia、NativeWindなど）が収録されています。 **次のような場合に使用:** - 既存のExpoアプリにサードパーティ製のライブラリやサービスを組み込む際に、推奨される標準的なやり方を参考にしたい場合 - バージョンが合致したパターンを新しいプロジェクトに適用したい場合 - `npx create-expo --example` コマンドを使ってサンプルプロジェクトから新規プロジェクトを作成する場合
Framework (OSS). Expo's official example projects - the expo/examples repo of ~70 `with-*` integrations (Stripe, Clerk, Supabase, OpenAI, maps, Reanimated, SQLite, Skia, NativeWind, and more). Use when integrating a third-party library or service into an existing Expo app and you want the canonical, version-matched pattern to adapt, or when scaffolding a new project from one with `npx create-expo --example`.
expo/examplesはExpoの公式ライブラリで、約70個の統合例（with-<ライブラリ>という名前のディレクトリ、例えばwith-stripeやwith-maps）を収録しています。各例は1つのライブラリやサービスを中心に構成されています。これらは完全なアプリではなく、マネージド型プロジェクト（ios/やandroid/フォルダがなく、ネイティブ設定はコンフィグプラグイン経由）で、通常は1画面あたり100～200行程度です。正規の統合パターン（依存パッケージの構成、app.jsonのコンフィグプラグイン、Expoが現在のSDKに対して保守している最小限の配線）を参考にして、ユーザーのアプリに合わせて調整してください。これらからアプリケーションアーキテクチャ全体を流用することは想定していません。
統合を手作りする前に、まず例を探してみてください。（フルスタック、ショーケース、スターターなどの種類は./references/catalog.mdに記載されています。）
ユーザーのニーズを例の名前にマップします（例：支払い → with-stripe、認証 → with-clerk）。./references/catalog.mdは分類されたスナップショットで素早く確認できますが、内容が変わることがあるため、ライブリストで確認してください：
# ライブの例の名前:
gh api repos/expo/examples/contents --jq '.[] | select(.type=="dir" and (.name|startswith(".")|not)) | .name'
# エイリアス（名前変更）と廃止予定（削除・移動）の例 — 推奨する前に確認:
gh api repos/expo/examples/contents/meta.json --jq '.content' | base64 -d
meta.jsonは名前変更や廃止例の信頼できるソースです。廃止予定の例は、それぞれmessageを含むdeprecatedマップにあります。例がdeprecatedマップにある場合は、推奨しないでください。messageに従ってモダンなパスを見つけてください。aliasesにある場合は、destinationを使用してください。
一般的なケース：ユーザーがすでにアプリを持っていて、Expoがどのように何かを実装しているかを知りたい場合。例を参考資料として読み、パターンを手作業で適用してください。例をユーザーのプロジェクトの上に直接スキャフォルドしないでください。
まず、1回の呼び出しで例全体をリストします。 統合コードは入れ子になっていることが多い（例：Stripeのサーバールートはapp/api/にあります）ため、1レベルのリストでは重要なファイルが漏れます：
gh api 'repos/expo/examples/git/trees/master?recursive=1' \
--jq '.tree[].path | select(startswith("with-stripe/"))'
次に、信号価値の高いファイルから読みます： README.md（セットアップ）→ package.json（依存パッケージ）→ app.json（コンフィグプラグイン・パーミッション）→ マニフェストが示した統合コード → .env（必要なシークレット）。ファイルごとに：
gh api repos/expo/examples/contents/with-stripe/utils/stripe-server.ts --jq '.content' | base64 -d
# ghがない場合は、Raw URL（ブランチはmaster）を使用:
curl -s https://raw.githubusercontent.com/expo/examples/master/with-stripe/utils/stripe-server.ts
複数のファイルを読むのですか？ 多くの統合は、サーバールート、クライアントプロバイダ、コンフィグ全体に広がっています（Stripeはそうです）。ファイルごとの呼び出しをスキップしてください。例全体を一時的なディレクトリ（ユーザーのプロジェクトではなく、.gitignoreされたディレクトリ）に取得し、Grep/Readで自由に読んでから、手作業で適用してください：
npx degit expo/examples/with-stripe /tmp/expo-ref/with-stripe # クリーンなコピー、Git履歴なし
# degitなしの代替案（スパースチェックアウト、約64 MBの完全クローンなし）:
git clone --depth 1 --filter=blob:none --sparse https://github.com/expo/examples.git /tmp/expo-ref/examples \
&& (cd /tmp/expo-ref/examples && git sparse-checkout set with-stripe)
そこからGrep/Readで読み、完了時に一時ディレクトリを削除します。
npx create-expo --example with-stripe # 短縮形: npx create-expo -e with-stripe
bun create expo --example with-stripe # bunを使う場合
ユーザーがすでにアプリを持っている場合、例が導入するもののみを追加し、既存のセットアップを上書きしないでください。
package.jsonのピンされたバージョンはより古いプロジェクトと一致しません。代わりにnpx expo install <pkg>で不足している依存パッケージのみを追加してください（SDK対応バージョンを自動解決します）。正確なバージョンをコピーしないでください。app.json/app.config.*のプラグインとパーミッションのみを追加してください。既存のコンフィグブロックはそのまま保持します。.envの形状から — プレースホルダーが含まれており、実際のシークレットは含まれていません。完了の目安は、 統合コードが移植され、それが必要とするあらゆる依存パッケージ、コンフィグプラグイン、パーミッション、環境変数がユーザーのアプリで考慮されている場合です。単に配線されているように見える時点ではありません。
master**であり、mainではありません（Raw URLとスパースチェックアウトで重要）。https://launch.expo.dev/?github=https://github.com/expo/examples/tree/master/<example>expo-tailwind-setupexpo-uiexpo-native-uiexpo-routerexpo-moduleexpo-upgrade./references/catalog.md — 素早く確認するための分類されたスナップショット。このスキルでエラー、誤解を招く、または古い情報が見つかった場合は、報告してExpoが改善できるようにしてください：
npx --yes submit-expo-feedback@latest --category skills --subject "expo-examples" "<実行可能なフィードバック>"
具体的かつ実行可能な内容がある場合のみ送信してください。可能な限り関連するコンテキストを含めてください。
AIエージェントが繰り返し失敗したか、ユーザーがExpoタスクを引き継いだ場合は、expo-skill-feedbackスキルを読み込んで、上記のコマンドを再利用する代わりに、eval-candidateフローに従ってください。
expo/examples is Expo's official library of ~70 integration examples — directories named with-<library> (e.g. with-stripe, with-maps), each built around one library or service. These are not full apps: they're managed projects (no ios//android/ dirs — native setup is via config plugins), and the typical one is a single screen of ~100–200 lines. Mine them for the canonical integration pattern — the dependency set, app.json config plugins, and minimal wiring Expo maintains against the current SDK — and adapt that into the user's app. Don't expect to lift an application architecture from them.
Reach for an example before hand-rolling an integration. (Kinds — full-stack, showcases, starters — are noted in ./references/catalog.md.)
Map the user's need to an example name (e.g. payments → with-stripe, auth → with-clerk). ./references/catalog.md is a categorized snapshot for fast triage — but it drifts, so confirm against the live list:
# Live example names:
gh api repos/expo/examples/contents --jq '.[] | select(.type=="dir" and (.name|startswith(".")|not)) | .name'
# Aliases (renamed) + deprecated (dead/moved) examples — check before recommending:
gh api repos/expo/examples/contents/meta.json --jq '.content' | base64 -d
meta.json is the source of truth for what's renamed or dead (deprecated examples are removed from the repo tree but still listed here, each with a message). If an example is in its deprecated map, don't recommend it — follow the message to the modern path. If it's in aliases, use the destination.
The common case: the user already has an app and wants to see how Expo does something. Read the example as reference and apply the patterns by hand — never scaffold an example on top of their project.
First, list the whole example in one call. Integration code is often nested (e.g. Stripe's server routes live in app/api/), so a one-level listing misses the important files:
gh api 'repos/expo/examples/git/trees/master?recursive=1' \
--jq '.tree[].path | select(startswith("with-stripe/"))'
Then read the high-signal files first: README.md (setup) → package.json (deps) → app.json (config plugins / permissions) → the integration code the manifest revealed → .env (required secrets). Per file:
gh api repos/expo/examples/contents/with-stripe/utils/stripe-server.ts --jq '.content' | base64 -d
# No gh? Raw URL (branch is master):
curl -s https://raw.githubusercontent.com/expo/examples/master/with-stripe/utils/stripe-server.ts
Reading more than a couple of files? Many integrations are spread across server routes, a client provider, and config (Stripe is). Skip the per-file calls — pull the whole example into a throwaway/gitignored dir (not the user's project) and read it freely with Grep/Read, then apply by hand:
npx degit expo/examples/with-stripe /tmp/expo-ref/with-stripe # clean copy, no git history
# fallback without degit (sparse-checkout, no full ~64 MB clone):
git clone --depth 1 --filter=blob:none --sparse https://github.com/expo/examples.git /tmp/expo-ref/examples \
&& (cd /tmp/expo-ref/examples && git sparse-checkout set with-stripe)
Read from there with Grep/Read; delete the scratch dir when done.
npx create-expo --example with-stripe # short form: npx create-expo -e with-stripe
bun create expo --example with-stripe # with bun
When the user already has an app, add only what the example introduces; never overwrite their setup.
package.json pins won't match an older project. Add only the missing deps with npx expo install <pkg> (it resolves SDK-correct versions) instead of copying exact versions.app.json/app.config.* plugins and permissions the example introduces that the user lacks — keep their existing config block intact..env shape — it holds placeholders, never working secrets.Done when the integration code is ported and every dependency, config plugin, permission, and env var it needs is accounted for in the user's app — not when it merely looks wired up.
master, not main (matters for raw URLs and sparse checkout).https://launch.expo.dev/?github=https://github.com/expo/examples/tree/master/<example>.expo-tailwind-setupexpo-uiexpo-native-uiexpo-routerexpo-moduleexpo-upgrade./references/catalog.md — categorized snapshot of the example library for fast triage.If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:
npx --yes submit-expo-feedback@latest --category skills --subject "expo-examples" "<actionable feedback>"
Only submit when you have something specific and actionable to report. Include as much relevant context as possible. If an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。