[Phase1] Supabase init + ローカル起動手順をREADMEに追加 - #29
Conversation
supabase init でsupabase/config.tomlを生成。CIのSupabase CLIバージョン (2.111.0)とローカルを揃える方針をREADMEに明記。この環境にはDockerが無く supabase startはローカル検証できないため、CI(.github/workflows/supabase.yml) のdb-test/types-checkが実行経路に切り替わることで動作確認する。 Closes #23
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| yarn install | ||
| cp .env.example .env.local # Supabaseの接続情報を設定 | ||
| supabase start # ローカルDB | ||
| npx supabase@2.111.0 start # ローカルDB(Dockerが必要) |
There was a problem hiding this comment.
nit: バージョン 2.111.0 が .github/workflows/supabase.yml の SUPABASE_CLI_VERSION とここの2箇所に手書きで重複しています。両者を揃える運用はコメント(L39)で明記されていますが、ずれても機械的に検出する手段が今は無く「気づかず放置」されうる状態です(CLAUDE.mdの「これは機械が止められるか」の観点)。将来的にはREADMEからワークフローの値を参照する形にするか、CIでバージョン文字列の一致をチェックするステップを足すと安全かもしれません。今回のPRをブロックするものではありません。
レビュー総評このPRは
インラインで1点、nitpickをコメントしました(README内のCLIバージョンがワークフローと2箇所で手書き重複しており、将来ずれても機械的に検出できない点)。ブロッカーではありません。 Dockerがこの作業環境に無く |
There was a problem hiding this comment.
Pull request overview
Issue #23 の対応として、Supabase のローカル開発/CI 実行の前提となる supabase init 相当の初期ファイルを追加し、README にローカル起動手順と Supabase CLI バージョン固定の注意を追記するPRです。以降の Phase1（マイグレーション/RLS/型生成/db test）に入るための土台を整える変更になっています。
Changes:
supabase/config.tomlを追加して Supabase ローカル設定を導入supabase/.gitignoreを追加して Supabase 作業ディレクトリ等を除外- README のセットアップ手順に Supabase CLI バージョン固定と
supabase startの実行例を追記
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| supabase/config.toml | Supabase ローカル開発用の設定ファイルを追加 |
| supabase/.gitignore | Supabase の作業ディレクトリ/ローカルdotenv系を ignore 対象に追加 |
| supabase/.gitkeep | Supabase ディレクトリのプレースホルダを削除 |
| README.md | ローカル起動手順に Supabase CLI バージョン固定と起動コマンド例を追記 |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # If enabled, seeds the database after migrations during a db reset. | ||
| enabled = true | ||
| # Specifies an ordered list of seed files to load during db reset. | ||
| # Supports glob patterns relative to supabase directory: "./seeds/*.sql" | ||
| sql_paths = ["./seed.sql"] |
この環境にはDockerが無くyarn gen:types --localをローカル実行できないため、 CIでの生成結果を取得してコミットできるようにする。
この環境にはDockerが無くyarn gen:types --localをローカル実行できないため、 CI(types-checkジョブ)のartifactからyarn gen:types相当の出力をそのまま 配置した。マイグレーション追加時(#24)に再生成が必要になる。
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.
Suppressed comments (3)
supabase/config.toml:71
[db.seed]がsql_paths = ["./seed.sql"]を参照していますが、リポジトリ内にsupabase/seed.sqlが存在しません（現状supabase/には config.toml と .gitignore のみ）。supabase db resetや CLI の挙動によっては起動/リセットが失敗する可能性があるため、seed ファイルを追加するまで seeding を無効化するか、sql_pathsを空にしてください。
enabled = true
# Specifies an ordered list of seed files to load during db reset.
# Supports glob patterns relative to supabase directory: "./seeds/*.sql"
sql_paths = ["./seed.sql"]
README.md:46
- README で「Supabase CLIは
.github/workflows/supabase.ymlのSUPABASE_CLI_VERSIONと同じ」と明記している一方、コマンド側で2.111.0を直書きしているため、Workflow 側のバージョン更新時にREADMEだけ古くなりやすいです。README上は値を固定せず、SUPABASE_CLI_VERSIONを参照して合わせる前提の書き方に寄せるのが安全です。
npx supabase@2.111.0 start # ローカルDB(Dockerが必要)
supabase/config.toml:163
auth.site_urlがhttp://127.0.0.1:3000なのに対して、additional_redirect_urlsがhttps://127.0.0.1:3000のみになっています。ローカル開発（READMEのyarn dev想定）では http で動くため、OAuth/redirect の許可リストが一致せず認証フローが失敗しやすいです。少なくとも http を含め、必要なら https も併記する形にしてください。
site_url = "http://127.0.0.1:3000"
# The public URL that Auth serves on. Defaults to the API external URL with `/auth/v1` appended.
# external_url = ""
# A list of *exact* URLs that auth providers are permitted to redirect to post authentication.
additional_redirect_urls = ["https://127.0.0.1:3000"]
| - uses: actions/upload-artifact@v4 | ||
| if: steps.check.outputs.initialized == 'true' | ||
| with: | ||
| name: supabase-types | ||
| path: supabase/types.ts |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 6 changed files in this pull request and generated no new comments.
Suppressed comments (4)
supabase/config.toml:71
[db.seed]がenabled = trueかつsql_paths = ["./seed.sql"]になっていますが、リポジトリ内にsupabase/seed.sqlが存在しないため、supabase db reset等で seed 読み込みが走った場合に失敗する可能性があります。seed を用意するまで一旦無効化するか、seed ファイルを追加してください。
# If enabled, seeds the database after migrations during a db reset.
enabled = true
# Specifies an ordered list of seed files to load during db reset.
# Supports glob patterns relative to supabase directory: "./seeds/*.sql"
sql_paths = ["./seed.sql"]
README.md:46
- README のコマンド例で Supabase CLI バージョンを
2.111.0にハードコードすると、workflow 側のSUPABASE_CLI_VERSION更新時にドキュメントだけが古くなるリスクがあります。バージョン値はプレースホルダにして、上の説明どおり workflow の値に合わせて置き換える形にするとズレを防げます。
npx supabase@2.111.0 start # ローカルDB(Dockerが必要)
.github/workflows/supabase.yml:91
- このコメント内の
yarn gen:types --localは、package.json のスクリプト名と一致していません（実際はyarn gen:typesが--localを内包しています）。手順名を正しいものに揃えてください。
# ローカル開発機にDockerが無く `yarn gen:types --local` を手元で実行できない
# 場合でも、生成結果をここから取得してコミットできるようにする。
supabase/types.ts:3
- PR説明の「変更内容」には
supabase/types.tsの追加と workflow の artifact upload 追加が含まれていません。差分自体は妥当ですが、レビュー/運用上の前提が変わるので PR説明側も更新して変更点を列挙してください。
export type Json =
| string
| number
| enabled = true | ||
| # Specifies an ordered list of seed files to load during db reset. | ||
| # Supports glob patterns relative to supabase directory: "./seeds/*.sql" | ||
| sql_paths = ["./seed.sql"] |
There was a problem hiding this comment.
[db.seed] enabled = true で sql_paths = ["./seed.sql"] を参照していますが、supabase/seed.sql はこのPRに含まれておらず、リポジトリ上に存在しません。
これはグロブパターンではなく固定パスなので、ファイルが無いと supabase start / db reset 実行時に読み込みエラーになる可能性があります。今回まさにこのPRで db-test / types-check の実行経路(supabase start を伴う)への切り替えを検証しようとしているので、ここで失敗すると「マイグレーション忘れ」でも「CLI差」でもない、seedファイル欠如というノイズでCIが赤くなり、CIの信頼性を損ないます。
空の supabase/seed.sql を追加するか、シードデータが用意できるフェーズまで sql_paths = [](または enabled = false)にしておくのが安全だと思います。CIの db-test/types-check が実際に緑になっているか確認をお願いします。
| yarn install | ||
| cp .env.example .env.local # Supabaseの接続情報を設定 | ||
| supabase start # ローカルDB | ||
| npx supabase@2.111.0 start # ローカルDB(Dockerが必要) |
There was a problem hiding this comment.
nitpick: 直前の行で「.github/workflows/supabase.yml の SUPABASE_CLI_VERSION と同じバージョンを使うこと」と明記している一方、ここでは 2.111.0 を直書きしています。ワークフロー側のバージョンが将来上がったとき、README側は文章だけ読むと「揃える方針」に見えて実際には自動で追従せず、無言でズレます(このリポジトリの「人間がdiffを読まない」前提だと特に気づきにくい)。
ブロッカーではありませんが、SUPABASE_CLI_VERSION を更新する際はREADMEのこの行も一緒に直す、という運用ルールをどこかに書いておくか、バージョン番号をコメントで「(supabase.ymlのSUPABASE_CLI_VERSIONと同じ値にすること)」と注記しておくと、ズレたときに気づきやすくなります。
| # The public URL that Auth serves on. Defaults to the API external URL with `/auth/v1` appended. | ||
| # external_url = "" | ||
| # A list of *exact* URLs that auth providers are permitted to redirect to post authentication. | ||
| additional_redirect_urls = ["https://127.0.0.1:3000"] |
There was a problem hiding this comment.
nitpick(低優先度): site_url = "http://127.0.0.1:3000" に対して additional_redirect_urls は https://127.0.0.1:3000 のみで、httpのURLが許可リストに入っていません。これは supabase init のデフォルトテンプレートそのままなので今回の変更で持ち込まれた問題ではありませんが、docs/roadmap.md フェーズ1に「Google SSO (Supabase Auth) の設定」があるため、そのタイミングでローカルの yarn dev(http)からのOAuthリダイレクトが弾かれる可能性があります。今すぐの修正は不要ですが、SSO実装時に踏む地雷として頭に入れておくとよさそうです。
レビュー総評このPRは
その上で、config.tomlの中身に実行時のリスクを1点見つけました。
軽微な指摘として、READMEでのSupabase CLIバージョンの直書き重複(ワークフロー側と2箇所で手で揃える形になっている)と、
|
存在しないsupabase/seed.sqlを固定パス参照したままだとsupabase start/db reset 実行時に失敗しうるため、シードデータが無い間はdb.seedを無効化する。 READMEのCLIバージョンにも「ワークフローと同じ値にすること」を注記し、 機械的に検出できないズレに気づきやすくする。
レビュー指摘の分類
|
総評Phase1の土台づくりとして妥当なスコープ。 良い点
気になった点(ブロッカーではない)
確認したこと
インライン指摘は別途投稿する。 |
| yarn install | ||
| cp .env.example .env.local # Supabaseの接続情報を設定 | ||
| supabase start # ローカルDB | ||
| npx supabase@2.111.0 start # ローカルDB(Dockerが必要。バージョンは.github/workflows/supabase.ymlのSUPABASE_CLI_VERSIONと同じ値にすること) |
There was a problem hiding this comment.
バージョン 2.111.0 を直書きしているため、.github/workflows/supabase.yml の SUPABASE_CLI_VERSION が将来更新された際にここが追従する保証がない(CIはREADMEの文字列までは検証しない)。このリポジトリの方針(CLAUDE.md「壊れたらCIが赤くなることで品質を担保する」)からすると、静かにズレうる箇所。実害は小さいが、コメントで「更新時はここも合わせる」旨を明記しておくと事故を防げる。
| @@ -0,0 +1,8 @@ | |||
| # Supabase | |||
There was a problem hiding this comment.
nitpick: ルートの .gitignore に既に supabase/.branches / supabase/.temp の無視ルールがあり、ここと二重管理になっている(書式は異なる: ルート側は supabase/.env 単体を無視、こちらは .env.keys / .env.local / .env.*.local のパターン)。実害はないが、無視ルールの置き場所がルートとサブディレクトリに分散すると、どちらが正か把握しづらくなる。supabase init の既定生成物なのでこのままでも良いが、気になるなら重複分はルート側から削ってこちらに一本化してもよさそう。
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 6 changed files in this pull request and generated no new comments.
Suppressed comments (3)
.github/workflows/supabase.yml:91
- ワークフローのコメントが実際のスクリプトと一致していません。
yarn gen:typesは package.json で既に--localを含むため、ここでyarn gen:types --localと書くと誤解を招きます。
# ローカル開発機にDockerが無く `yarn gen:types --local` を手元で実行できない
# 場合でも、生成結果をここから取得してコミットできるようにする。
supabase/types.ts:178
supabase/types.tsにas constが含まれており、CLAUDE.md の「asによるキャストを使わない」というルールと衝突します。生成ファイルとして例外扱いするのか、生成方法/チェック方法を調整するのかを明確にした方がよいです。
} as const
.github/workflows/supabase.yml:96
- PR説明の「変更内容」に、このワークフロー変更(生成型をartifactとしてアップロードする)と
supabase/types.tsの追加が含まれていません。CI挙動や成果物の扱いが変わるので、変更点として明示した方がレビュワー/後追いが迷いません。
- uses: actions/upload-artifact@v4
if: steps.check.outputs.initialized == 'true'
with:
name: supabase-types
path: supabase/types.ts
PR #68 のClaude Reviewの指摘に対応。指摘は正しかった。 誤り: 「300行を超えた5本」は事実と異なり、素の差分では9本だった (#31 307 / #59 365 / #60 380 / #30 441 / #29 617 / #18 679 / #41 698 / #32 1063 / #16 3528)。同じ本文が書いていた「300行以下が65%(17/26)」は 超過9本を含意しており、記述が自己矛盾していた。 原因: 母集団の統計(中央値・65%)は素の差分で数え、外れ値の説明だけに 除外規則を適用していた。数え方を混在させたうえ、超過リストを上位5本で 打ち切って全件確認しなかった。 訂正: 26本すべてを git show --numstat で数え直し、除外の段階ごとに 表で示す。素の差分(中央値135行 / 65% / 超過9本)、パス名で機械的に 判定できる除外まで(中央値128行 / 85% / 超過4本)、除外規則を最後まで 適用(超過2本 = #59・#60)。落ちる7本の内訳も明記した。 あわせて、3段階目の中央値を出さない理由を書いた。supabase/config.toml は #29 では supabase init の出力(416行)、#56 では根拠コメント付きで手で 直した6行で、同じパスでも扱いが逆になる。パス名では決まらないことが、 この節が機械的ゲートになり得ない理由そのものなので、「lintではない」の 段落の根拠もこの実測に差し替えた。 Refs #44
* docs: Issueの粒度とPR差分サイズの目安をCLAUDE.mdに明文化 判断ポイントは1 Issueに3個まで(5個超で分割)、PR差分は300行を目安とする。 記事の実測値をそのまま採らず、main にマージ済みのPR 26本(中央値135行、 300行以下65%)で裏を取ってから採用した。行数の数え方から生成物・ロック ファイル・権限マトリクスを写したテスト表を除外する根拠も、超過した PR #16 / #32 の実態から示した。 機械的ゲートにしない旨と、3回ルール(モデルを上げる) / PO確認(判断を 下せる層に上げる) / 粒度超過(Issueを分ける)の対処の違いを表で整理。 docs/roadmap.md はポインタ1行に留め、根拠は1箇所にだけ置く。 Refs #44 * docs: 判断ポイント数の境界を一本化し、裏取り済みの数値と外部実測を書き分ける PR #68 のClaude Reviewの指摘2件に対応。 指摘1: 「3個まで、5個を超えるなら分割」で4個の扱いが未定義だった。 閾値を「3個まで。4個目が出てきたら分ける」に一本化する。機械的ゲートに しない方針である以上、「検討」と「必ず」の二段構えは実効性のない false precisionになるため、緩衝域を作らず単一の線にした。 指摘2: 裏取り済みの300行と、外部実測のままの3個が同じ文脈に並んでいた。 「2つの数字は裏付けの強さが違う」として段落を分け、300行はこのリポジトリの 実測(PR 26本、中央値135行/300行以下65%)で検証済み、3個は外部実測のみを 根拠とする未検証のヒューリスティックであると明示した。過去Issueの判断数は 記録がなく後から数え直せないため、このリポジトリでの裏取りが今はできない 理由も併記。採用の根拠はコストの非対称性に置いた。 あわせて、外部実測に対応値のない4個/5個を推定して線を引いていないことと、 実績が溜まったら見直す旨を記載した。 Refs #44 * docs: PR実測の集計を数え直し、超過本数の誤りを訂正する PR #68 のClaude Reviewの指摘に対応。指摘は正しかった。 誤り: 「300行を超えた5本」は事実と異なり、素の差分では9本だった (#31 307 / #59 365 / #60 380 / #30 441 / #29 617 / #18 679 / #41 698 / #32 1063 / #16 3528)。同じ本文が書いていた「300行以下が65%(17/26)」は 超過9本を含意しており、記述が自己矛盾していた。 原因: 母集団の統計(中央値・65%)は素の差分で数え、外れ値の説明だけに 除外規則を適用していた。数え方を混在させたうえ、超過リストを上位5本で 打ち切って全件確認しなかった。 訂正: 26本すべてを git show --numstat で数え直し、除外の段階ごとに 表で示す。素の差分(中央値135行 / 65% / 超過9本)、パス名で機械的に 判定できる除外まで(中央値128行 / 85% / 超過4本)、除外規則を最後まで 適用(超過2本 = #59・#60)。落ちる7本の内訳も明記した。 あわせて、3段階目の中央値を出さない理由を書いた。supabase/config.toml は #29 では supabase init の出力(416行)、#56 では根拠コメント付きで手で 直した6行で、同じパスでも扱いが逆になる。パス名では決まらないことが、 この節が機械的ゲートになり得ない理由そのものなので、「lintではない」の 段落の根拠もこの実測に差し替えた。 Refs #44 * docs: PR #29/#32の除外理由が2段階なのに1段階しか書いていなかった記述漏れを修正 Claude Reviewの指摘どおり、#29(617→22)はsupabase/config.toml(416行) だけでなくsupabase/types.ts(179行)も、#32(1063→79)はテスト表(924行) だけでなくyarn.lock(60行)も除外して初めて数字が再現できる。 片方しか書いていなかったため、追試すると数値が合わなかった。 Refs #44
概要
Issue #23 の対応。
supabase initを実行しsupabase/config.tomlを生成。以降のPhase1作業(マイグレーション・RLS・型生成・db test)の前提を整える。変更内容
supabase/config.toml/supabase/.gitignoreを追加(supabase/.gitkeepは不要になったため削除).github/workflows/supabase.ymlのSUPABASE_CLI_VERSION=2.111.0)と揃える旨を追記注意
この作業環境にはDockerが無く、
supabase startはローカルで検証できない。supabase init(Docker不要)のみこの環境で実施し、実際の起動確認は本PRのCI(db-test/types-checkジョブがスキップ経路ではなく実行経路に切り替わるか)で行う。確認したこと
yarn lint/yarn typecheck/yarn testが通ることを確認.github/workflows/supabase.ymlのdb-test/types-checkがsupabase/config.tomlを検出し、実行経路(supabase start等)に切り替わることを確認するTest plan
db-test/types-checkが実行経路(スキップでなくsupabase startを伴う)で成功する