Local Supabase development (test env instead of prod) - #291
Open
plusmobileapps wants to merge 4 commits into
Open
Local Supabase development (test env instead of prod)#291plusmobileapps wants to merge 4 commits into
plusmobileapps wants to merge 4 commits into
Conversation
Run `supabase init` and commit the local stack config so the existing TESTING environment can point at a local Supabase backend instead of prod. - config.toml: project_id "chef-mate", enable anonymous sign-ins (the app bootstraps an anon session on start), disable email confirmations, wire seed.sql. - seed.sql (local-only, never pushed): recreate the recipe-photos/avatars buckets + RLS policies (mirroring docs/supabase-*-setup.sql) and seed two confirmed test users for the Developer Settings "Login as test user" flow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a debug-only network security config permitting cleartext HTTP to the local Supabase stack (10.0.2.2 from the emulator, localhost) so Android debug builds can reach it during development. Release builds keep Android's default (cleartext blocked). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Document developing against a local Supabase stack instead of prod: prereqs, the one-time `supabase db pull` baseline (prod's base tables have no migration), starting the stack, wiring supabase.testing.* in local.properties, per-platform networking (localhost vs 10.0.2.2), edge functions, troubleshooting, a hosted staging alternative, and an appendix on reconciling prod's migration history for future CLI pushes. Cross-link from README, buildconfig-setup, and developer-settings. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The prod schema was built largely by hand, so the base tables (recipes, profiles, grocery, meal_plans) never had migration files and three migrations shared the version 20260610 — replaying the incrementals against a fresh DB can't work (ordering + duplicate-version collision in the history table). Move the 9 incrementals to supabase/archived_migrations/ (history-only, never applied or pushed) and leave supabase/migrations/ empty for a squashed baseline. Developers generate the baseline once with `supabase db dump` (read-only) — see the updated guide. Update docs to use db dump instead of db pull and reduce prod reconciliation to a single `migration repair`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Enables developing ChefMate against a local Supabase stack (Docker) instead of testing against the production project, and documents the workflow. The client already had a
TESTINGenvironment baked in — this adds the backend config and the bits needed to pointTESTINGat a local stack.Changes
chore(supabase)— CLI configsupabase initoutput committed:supabase/config.toml(project_id = "chef-mate", anonymous sign-ins enabled, email confirmations off, seed wired) +supabase/.gitignore.supabase/seed.sql(local-only, never pushed): recreates therecipe-photos/avatarsbuckets + RLS policies and seeds two confirmed test users (alice@chefmate.test,bob@chefmate.test, pwpassword123) for the Developer Settings "Login as test user" flow.chore(supabase)— squashed migrationsrecipes,profiles, grocery,meal_plans) never had migration files, and three migrations shared the version20260610. Replaying the incrementals against a fresh DB can't work (ordering + duplicate-version collision). Moved the 9 incrementals tosupabase/archived_migrations/(history-only, never applied/pushed);supabase/migrations/is left empty for a squashed baseline a dev generates once viasupabase db dump.feat(android)— emulator connectivitynetwork_security_config.xml+ manifest overlay permitting cleartext HTTP to10.0.2.2/localhost. Release builds keep Android's default (cleartext blocked).docsdocs/supabase-local-development.md: prereqs, the one-timesupabase db dumpbaseline, starting the stack,local.propertieswiring, per-platform networking, edge functions, troubleshooting, hosted-staging alternative, and a prod history-reconciliation appendix (migration repair).buildconfig-setup.md,developer-settings.md.Prod's schema was built by hand via the dashboard, so there was never a migration for the base tables. Rather than ship broken incrementals, the guide has each dev snapshot prod once with
supabase db dump --linked --schema public -f supabase/migrations/<ts>_baseline.sql(read-only). The original incrementals are preserved undersupabase/archived_migrations/for history.Testing
Not yet exercised against a live stack —
supabase db dump/start/db resetand an Android debug build were not run here (image pull is heavy; the dump needs prod credentials). The seed SQL and debug manifest merge are standard patterns but unverified end-to-end; the firstsupabase db resetis the real test.🤖 Generated with Claude Code