tina-schema-sync について
TinaCMS のスキーマ変更後に、生成物を再生成してコミットするスキルです。`tinacms dev` によるローカル生成、検証、デプロイ準備を案内し、`tinacms build` でコンテンツをシードできない場合にも対応します。
主な機能
- 01`tinacms dev` で生成物を再生成
- 02生成型とロックファイルを検証
- 03認証情報とローカルポートを確認
- 04生成ファイルをまとめてコミット
- 05スキーマ同期エラーを調査
活用シーン
- 01`tina/config.ts` 編集後の生成物同期
- 02生成時の未知のブロック型への対応
- 03Vercel デプロイ用スキーマ生成物の準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ genericservice/ claude-skills --skill tina-schema-syncインストール後、Claude Code で/tina-schema-syncを入力して読み込まれたか確認します。
詳細
TinaCMS スキーマ同期
スキーマを変更した後、TinaCMS のアーティファクトをローカルで再生成し、コミットします。これは、Vercel では tinacms build をスキップし、アーティファクトを事前にコミットするハイブリッドデプロイ戦略に対応します。
使用するタイミング
tina/config.tsを編集した後(フィールド、ブロック、コレクションの追加)@tinacms/cliをアップグレードした後pnpm tina:buildが「Unable to seed」で失敗したとき(コンテンツが不明なブロックタイプを参照している)- Vercel のデプロイは成功するものの、新しいブロックがレンダリングされないとき
前提条件
.env.localに TinaCloud の認証情報があること:NEXT_PUBLIC_TINA_CLIENT_ID="..." TINA_TOKEN="...".env.localがない場合は、./scripts/pull-secrets.shを実行するか、.env.exampleをコピーして、TinaCloud ダッシュボードの値を設定してください。
手順
ステップ 1:認証情報を読み込む
source .env.local
設定されていることを確認します:
echo $NEXT_PUBLIC_TINA_CLIENT_ID | head -c 10
echo $TINA_TOKEN | head -c 10
ステップ 2:開発サーバーを実行してアーティファクトを再生成する
NEXT_PUBLIC_TINA_CLIENT_ID="$NEXT_PUBLIC_TINA_CLIENT_ID" \
TINA_TOKEN="$TINA_TOKEN" \
npx tinacms dev --noWatch --noTelemetry
「TinaCMS Dev Server is active」というメッセージが表示されるまで待ち、その後サーバーを停止します(Ctrl+C またはプロセスを終了します)。
tinacms build ではなく tinacms dev を使う理由: ビルドコマンドはインデックス作成のために TinaCloud に接続します。コンテンツが、TinaCloud のスキーマで認識されていない新しいブロックタイプをすでに参照している場合、ビルドは「Unable to seed」で失敗します。開発サーバーは、TinaCloud に先に再インデックスを要求することなく、アーティファクトをローカルで生成します。
ステップ 3:アーティファクトが再生成されたことを確認する
git status tina/
次のファイルに変更があるはずです:
tina/__generated__/client.tstina/__generated__/types.tstina/tina-lock.json
public/admin/ にも変更がないか確認してください。
ステップ 4:新しい型が存在することを確認する
新しいブロックタイプ(例:ContentTypes)を追加した場合:
grep "ContentTypes" tina/__generated__/types.ts
ステップ 5:3 つすべてのアーティファクトグループをコミットする
git add tina/__generated__/ tina/tina-lock.json public/admin/
git commit -m "chore(tina): regenerate artifacts for [describe schema change]"
重要: tina/tina-lock.json は、デプロイ時に TinaCloud がスキーマを理解するために読み込むファイルです。生成された型をコミットしても、ロックファイルを忘れると、デプロイが失敗するか、新しいブロックタイプがレンダリングされません。
ステップ 6:プッシュする
git push
TinaCloud はプッシュされたコミットからロックファイルを取得し、スキーマを正しくインデックス化します。
エージェントワークフローとバイブコーディング
- 反復的な同期: 複雑なフィールド依存関係がある場合、スキーマが最初から完璧に同期されるとは限りません。開発サーバーでエラーが発生する場合や、アーティファクトが生成されない場合は、該当するスキーマエラーを特定し、コレクションまたはフィールド定義を 1 つだけ修正して、成功するまで同期プロセスを再実行してください。
- バイブコーディング: 同期プロセスを実行する前に、作業中の
tina/config.tsの変更をローカルで意味のあるコミットとして保存し、同期が成功した後で生成されたアーティファクトを別途コミットしてください。生成に失敗した場合でも、簡単にロールバックできます。
トラブルシューティング
「Unable to seed content/pages/home.mdx」
コンテンツファイルが、クラウドのスキーマで認識されていないブロックタイプを参照しています。これは、このスキルが対処するケースそのものです。tinacms build ではなく、tinacms dev(ステップ 2)を使ってください。
開発サーバーが起動しない
- 認証情報が設定されていることを確認します(ステップ 1)
- ポート 4001 が使用中でないことを確認します:
lsof -i :4001 - ポート 6970 が使用中でないことを確認します:
lsof -i :6970
型は生成されたが、ロックファイルに変更がない
スキーマの変更が保存されていない可能性があります。開発サーバーを実行する前に、tina/config.ts が書き込まれていることを確認してください。
チェックリスト
プッシュする前に、次の項目を確認してください:
-
tina/__generated__/client.tsに変更がある -
tina/__generated__/types.tsに新しい型定義がある -
tina/tina-lock.jsonに変更がある -
public/admin/が更新されている(該当する場合) - 4 つすべてがまとめてステージングされ、コミットされている