Firebase プロジェクトのディレクトリ構成 ベストプラクティス

まだ１つしかプロジェクト作ったことないのでベストもクソもないのですが、よく見かけるサンプルのディレクトリ構成に違和感があるもので。。。

対象プロジェクト

Firebase プロジェクトで Hosting と Functions を使い、かつ Hosting にデプロイするファイルを Webpack 等を用いてビルドする場合です。

ベストプラクティス

単純な話なのですが、Firebase プロジェクト直下に１つディレクトリを作成してこれを hosting プロジェクトのルートにするのがベストです。

<Filrebase Procject>/  # Firebase プロジェクトのルート
    firebase.json
    package.json
    hosting/           # Hosting プロジェクトのルート
        build/         # Hosting プロジェクトのビルド成果物 = Hosting のデプロイ対象
        src/           # Hosting プロジェクトのソース
        package.json
    functions/         # Functions プロジェクトのルート
        src/           # Functions プロジェクトのソース
        package.json

hosting と functions が横並びでディレクトリ構成が統一されます。
どう考えてもこれがキレイな構成ですよね。。。

firebase.jsonには Hosting プロジェクトのビルド成果物を公開ディレクトリとして設定します。

firebase.json

  "hosting": {
    "public": "hosting/build"

ルート直下の package.json にはデプロイスクリプトなどを登録しておきます。

package.json

 "scripts": {
    "deploy": "yarn --cwd hosting build && firebase deploy"
  }

よく見かけるサンプル(良くない例)

よく見かけるサンプルでは、Firebase プロジェクトのルート = Hosting プロジェクトのルート となっているものが多いです。

<Filrebase Procject>/  # Firebase プロジェクトのルート、Hosting プロジェクトのルート
  　　firebase.json
  　　build/            # Hosting プロジェクトのビルド成果物 = Hosting のデプロイ対象
  　　src/              # Hosting プロジェクトのソース
  　　package.json
  　　functions/        # Functions プロジェクトのルート
    　　  src/          # Functions プロジェクトの
    　　  package.json

Hosting だけのプロジェクトであればこれでもいいのですが、Functions も使うプロジェクトだと hosting と functions が入れ子になってしまいます。

どう考えても歪な構成ですよね。。。

作成手順が良くない？

このような歪なディレクトリ構成がまかり通っているのは、入門書などで以下のような順番で説明しているからではないでしょうか。

1. 最初にローカルで動く SPA を作成
2. SPA を Firebase プロジェクトにしてデプロイする
3. Functions を使用するコードを追加

最初にSPAとして作成して後付けで Firebase プロジェクトにすると、どうしてもFirebase プロジェクトのルート = Hosting プロジェクトのルート になってしまいます。。。