毎日firebase.jsonに足している
rewriteは、実は静的ランディング
ページには不要だった話
新規アプリを1本追加するたび、firebase.jsonのhosting.rewritesに/tools/{id}/**・/apps/{id}/**・/privacy/{id}/**の3行を機械的に足す運用をここ数日続けてきた。今日だけで4本、直近5日で合計20本追加している。改めて調べてみると、index.html 1枚だけの静的ランディングページには、この3行は本来なくても動くことが分かった。
Firebase Hostingは末尾スラッシュのディレクトリindexを標準で解決する
Firebase HostingはtrailingSlashの設定を明示しない場合、ディレクトリのindexファイル(例: about/index.html)についてのみ、標準で末尾スラッシュを使う。つまり/apps/origami-muse/のようなURLは、rewritesに何も書かなくてもp/apps/origami-muse/index.htmlを自動的に返す。これは静的ホスティングとしてごく一般的な挙動で、GitHub PagesやNetlifyのような他の静的ホストとも共通する。
rewriteの本来の役割はSPAのキャッチオール
firebase.jsonのrewrites設定は、本来「このURLパターンに一致したら、実ファイルの有無に関わらず必ずこのHTMLを返す」ためのものだ。SEADICEのリポジトリではtoite・rakuraku・lifeisrpg・kao_type_diag・focus-diceのような既存のFlutter SPAアプリが、まさにこの用途でrewriteを使っている。これらは/toite/settingsのような実ファイルが存在しない深いパスにもアクセスされる可能性があり、Flutterのクライアントサイドルーターに処理を渡すには、あらゆるサブパスをindex.htmlに着地させる必要がある。
| ページの種類 | rewriteの要否 | 理由 |
|---|---|---|
| Flutter SPA(toite・rakuraku等) | 必要 | 実ファイルが存在しない任意のサブパスにアクセスされ、クライアントルーターに処理を渡す必要がある |
| 静的ランディングページ(apps/tools/privacy配下の新規アプリ) | 不要 | ディレクトリにindex.htmlが1枚あるだけで、末尾スラッシュのURLは標準解決される |
それでも今日から書き方を変えないと決めた理由
結論としては、これまで通りrewriteを3行足す運用を継続する。冗長ではあっても実害がないうえ、いくつか具体的なメリットがあるからだ。
- 将来
trailingSlash設定やpublicディレクトリ構成を変更したときに、明示的なrewriteがあれば挙動が変わりにくい rewrites配列を見るだけで、そのアプリのURLが3種類(tools/apps/privacy)存在することが一覧で分かり、ドキュメント代わりになる- 本記事執筆時点で
CLAUDE.mdのチェックリストには「静的ディレクトリはrewrite不要」と明記されているが、実際の日次運用ではFlutter SPAとの区別を毎回考えるコストの方が、3行追加するコストより高い
この記事を書くきっかけになった調査結果は、CLAUDE.mdの「新規アプリをWebに追加するときのチェックリスト」節にすでに一行で書かれていた内容と一致する。ドキュメントに書いてあることを実際に手を動かして検証し直す、という遠回りをした形だが、なぜそのルールが正しいのかを理解した状態で運用を続けられるようになったのは収穫だった。
Today's App
Origami Muse - 気分やシーンを伝えるとAIが本物の折り紙モデルを提案するアプリ →
Related
新規アプリ公開後の「配線忘れ」をレジストリで自動化した話 →
← ブログ一覧に戻る