Durable Objects, Workers - Declare Durable Object class lifecycle with `exports`

Summary

Cloudflare Workers の Durable Objects 管理が、従来の順序付き migrations 配列から宣言的な exports マップへ移行しました。各 Durable Object クラスを現在の状態（created/renamed/deleted/transferred/expecting-transfer など）で定義し、Cloudflare が既存デプロイと比較して作成・削除・リネーム・転送の差分を適用します。既存の migrations を使っている Worker はそのまま動作しますが、exports と migrations は同一 Worker では併用できません。

Key Points

• 宣言的: exports は現在のクラスマップをソース・オブ・トゥルースとするため、タグ順序や履歴チェーンの管理不要。
• ライフサイクル状態: 各エントリは created（既定）／renamed／deleted／transferred／expecting-transfer などで状態を示す。リネームは元クラスを renamed にして renamed_to を指定するだけ。
• ゼロダウンタイム: トゥームストーン（tombstone）とソースクラスが共存できるため、3 段階リリースのリネームや 4 段階のクロスワーカー転送が安全に行える。
• デプロイ出力: Wrangler は作成・更新・削除・リネーム・転送の差分を構造化して報告し、不要な古いエントリも特定する。
• クロスワーカー安全性: クラスを削除/リネームする際、バインディングを参照する他の Worker を一覧表示するので、先にそれらを再デプロイできる。
• 併用ルール: exports と migrations は互いに排他。既存の migrations は無変更で動作するが、移行時は公式のマイグレーションガイドを参照すること。

Practical migration tips

• 小さく安全に移行する: まず exports に現在のクラスを反映し、リネームは renamed トゥームストーンを使って段階的にロールアウト。
• 確認フロー: Wrangler の差分出力を必ず確認し、他 Worker の参照一覧がないことを確認してから変更を確定する。
• 互換性: 既存の Workers が legacy migrations を使用している場合、それらを先に exports に移す必要はないが、同一 Worker 内で両方式を混在させない。

参照: Durable Object class exports（公式ドキュメントとマイグレーションガイド）