Implement local testing with supabase

[ch-iv]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
trcc	Error			Dec 10, 2025 6:04pm

[Copilot]

Pull request overview

This PR implements local testing infrastructure with Supabase, enabling developers to run integration tests against a local Supabase instance. The changes standardize environment variable naming, set up Vitest configuration with test helpers, add database migrations, and update CI workflows to support automated testing.

Key Changes

• Environment variable standardization: Migrated from NEXT_PUBLIC_SUPABASE_* to simpler API_URL and PUBLISHABLE_KEY conventions
• Test infrastructure setup: Added Vitest configuration with setup files, test helpers for Supabase client creation, and fixture utilities for creating test data
• Local development tooling: Added Supabase configuration and migration files for local database setup, plus npm script for database initialization

Reviewed changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 15 comments.

Show a summary per file

File	Description
vitest.config.ts	Configures Vitest to use test setup file for initialization
tests/setup.ts	Implements global test setup/teardown with database cleanup hooks
tests/helpers/supabase.ts	Provides test client creation and database cleanup utilities
tests/helpers/fixtures.ts	Adds fixture functions for creating test users and volunteers
tests/helpers/index.ts	Exports test helper modules
tests/lib/api/getExample.integration.test.ts	Demonstrates integration testing pattern with Supabase
supabase/migrations/20251210030724_remote_schema.sql	Defines database schema with tables, constraints, and RLS policies
supabase/config.toml	Configures local Supabase instance settings
supabase/.gitignore	Excludes Supabase temporary files from version control
src/lib/client/supabase/server.ts	Updates environment variable names for Supabase client creation
package.json	Adds dotenv dependency and db initialization script
package-lock.json	Updates dependency lock file with new and upgraded packages
.vscode/settings.json	Configures VS Code for Deno support in supabase/functions
.vscode/extensions.json	Updates recommended extensions for Deno development
.github/workflows/ci.yml	Adds database startup step to CI workflow

Comments suppressed due to low confidence (1)

supabase/migrations/20251210030724_remote_schema.sql:293

• The Row Level Security (RLS) policies grant full permissions (USING (true) WITH CHECK (true)) to anonymous users for all tables. While this may be intentional for the "development phase" as noted in the policy names, this configuration is extremely dangerous and should:

1. Never be deployed to production - This allows anyone to read, insert, update, and delete all data
2. Include prominent documentation warnings about these permissive policies
3. Have a plan/timeline for implementing proper RLS policies before production deployment

Consider adding comments in the migration file warning about these development-only policies and creating a tracking issue for implementing proper security policies.

CREATE POLICY "full permission for development phase" ON "public"."Cohorts" TO "anon" USING (true) WITH CHECK (true);



CREATE POLICY "full permission for development phase" ON "public"."Roles" TO "anon" USING (true) WITH CHECK (true);



CREATE POLICY "full permission for development phase" ON "public"."VolunteerCohorts" TO "anon" USING (true) WITH CHECK (true);



CREATE POLICY "full permission for development phase" ON "public"."VolunteerRoles" TO "anon" USING (true) WITH CHECK (true);



CREATE POLICY "full permissions for development phase" ON "public"."Volunteers" TO "anon" USING (true) WITH CHECK (true);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The createAnonTestClient function is identical to createTestClient. Both create clients with the same authentication configuration (autoRefreshToken: false, persistSession: false). Consider either:

1. Removing the duplicate function if they serve the same purpose
2. Differentiating them if they should have different behavior (e.g., different auth configs or keys)

Suggested change

	export function createAnonTestClient(): SupabaseClient<Database> {
	const { apiUrl, key } = getTestConfig();
	return createSupabaseClient<Database>(apiUrl, key, {
	auth: {
	autoRefreshToken: false,
	persistSession: false,
	},
	});
	}

[Copilot]

The TypeScript default formatter is set to Deno for all TypeScript files, but Deno should only be used for files in supabase/functions (as configured in line 5). This will cause formatting inconsistencies since the rest of the codebase uses Prettier. Consider either:

1. Removing this global TypeScript formatter override and letting it default to Prettier
2. Using a more specific configuration that only applies Deno formatting to files within supabase/functions

Suggested change

	"[typescript]": {
	"editor.defaultFormatter": "denoland.vscode-deno"
	},

[Copilot]

The deleteAllFromTables function lacks documentation explaining:

1. Why the specific deletion order is critical (foreign key constraints)
2. That it's used in test setup/teardown
3. Potential errors that could occur (permissions, constraints)
4. That it silently ignores errors

Adding JSDoc comments would help maintainers understand the function's purpose and behavior.

Suggested change

	/**
	* Deletes all rows from a set of tables in a specific order.
	*
	* The deletion order is critical due to foreign key constraints between tables.
	* This function is intended for use in test setup/teardown to ensure a clean database state.
	* Potential errors (such as permission issues or constraint violations) are silently ignored;
	* the function does not throw or log errors if deletions fail.
	*
	* @param client Supabase client instance connected to the test database.
	* @returns Promise that resolves when all deletions have been attempted.
	*/

[Copilot]

The db script uses rm .env which will fail on Windows systems (should use rimraf or a cross-platform alternative). Additionally, this script unconditionally removes the .env file, which could delete important environment variables that aren't generated by supabase status. Consider:

1. Using a cross-platform file removal tool or Node.js script
2. Backing up existing .env content or merging the output instead of overwriting
3. Creating a .env.local file specifically for local development

Suggested change

	"db": "npx supabase start && npx supabase migration up && rm .env && npx supabase status -o env >> .env"
	"db": "npx supabase start && npx supabase migration up && npx rimraf .env.local && npx supabase status -o env >> .env.local"

[Copilot]

The VS Code recommended extensions were replaced, removing ESLint and Prettier extensions and adding only Deno. However, the project still uses ESLint and Prettier (based on package.json and other config files). The Deno extension is only needed for supabase/functions directory. Consider keeping the ESLint and Prettier extensions in the recommendations alongside Deno, as they're still actively used in this project.

Suggested change

	"recommendations": ["denoland.vscode-deno"]
	"recommendations": [
	"denoland.vscode-deno",
	"dbaeumer.vscode-eslint",
	"esbenp.prettier-vscode"
	]

[Copilot]

Creating a new Supabase client for each beforeAll and afterAll hook may be inefficient. Consider creating a single client instance and reusing it, or at least document why separate clients are needed for setup and teardown.

Suggested change

	beforeAll(async () => {
	const client = createTestClient();
	await deleteAllFromTables(client);
	});
	afterAll(async () => {
	const client = createTestClient();
	const client = createTestClient();
	beforeAll(async () => {
	await deleteAllFromTables(client);
	});
	afterAll(async () => {

[Copilot]

Creating the test client at the module level (outside of test cases) means the client is initialized when the module loads, before the environment variables may be loaded by dotenv. This could cause initialization errors. Consider creating the client within each test or in a beforeEach hook to ensure proper initialization timing.

Suggested change

	const client = createTestClient();
	let client;
	beforeEach(() => {
	client = createTestClient();
	});

[Copilot]

The type assertion as unknown as Array<{ id: number }> on line 56 followed by a filter to ensure IDs are not undefined/null (lines 58-60) suggests a potential type mismatch. Consider using proper typing from the Database schema to avoid the need for these defensive checks, or at least add a comment explaining why the type assertion is necessary and what edge cases the filter is handling.

Suggested change

	const rows = allRows as unknown as Array<{ id: number }>;
	const ids = rows.map((row) => row.id);
	const filteredIds = ids.filter(
	(id): id is number => id !== undefined && id !== null
	// Use the correct type from the Database schema for rows
	type RowType = Database["public"]["Tables"][typeof tableName]["Row"];
	// The select("id") call returns Array<Pick<RowType, "id">>
	const ids = (allRows as Array<Pick<RowType, "id">>).map((row) => row.id);
	// If the id type is not guaranteed to be number, filter out undefined/null
	// (This filter is defensive; remove if schema guarantees id is always number)
	const filteredIds = ids.filter(
	(id): id is number => typeof id === "number"

[Copilot]

The test fixture functions createTestUser and createTestVolunteer lack JSDoc documentation. Consider adding documentation to explain:

1. The purpose of each function
2. Parameters and their types
3. What the overrides parameter does
4. Return value structure
5. Potential errors that might be thrown

This would improve developer experience when using these fixtures in tests.

[Copilot]

These row-level security policies grant the anon role USING (true) WITH CHECK (true) on Cohorts, Roles, VolunteerCohorts, VolunteerRoles, and Volunteers, which effectively gives any anonymous client full read/write access to all rows via the public anon key. An attacker who can call the Supabase REST/GraphQL endpoints anonymously can exfiltrate and arbitrarily modify sensitive volunteer-related data. Replace these policies with least-privilege RLS rules (e.g., restricted to authenticated users and/or row ownership) and, if you need unrestricted access for development, use a separate dev project or a non-anon role that is never exposed to untrusted clients.

Suggested change

	CREATE POLICY "full permission for development phase" ON "public"."Cohorts" TO "anon" USING (true) WITH CHECK (true);
	CREATE POLICY "full permission for development phase" ON "public"."Roles" TO "anon" USING (true) WITH CHECK (true);
	CREATE POLICY "full permission for development phase" ON "public"."VolunteerCohorts" TO "anon" USING (true) WITH CHECK (true);
	CREATE POLICY "full permission for development phase" ON "public"."VolunteerRoles" TO "anon" USING (true) WITH CHECK (true);
	CREATE POLICY "full permissions for development phase" ON "public"."Volunteers" TO "anon" USING (true) WITH CHECK (true);
	-- Remove permissive anon policies and replace with least-privilege policies
	-- Cohorts: Only authenticated users can read and write
	CREATE POLICY "select_cohorts_authenticated" ON "public"."Cohorts"
	FOR SELECT TO authenticated
	USING (true);
	CREATE POLICY "modify_cohorts_authenticated" ON "public"."Cohorts"
	FOR ALL TO authenticated
	USING (true) WITH CHECK (true);
	-- Roles: Only authenticated users can read and write
	CREATE POLICY "select_roles_authenticated" ON "public"."Roles"
	FOR SELECT TO authenticated
	USING (true);
	CREATE POLICY "modify_roles_authenticated" ON "public"."Roles"
	FOR ALL TO authenticated
	USING (true) WITH CHECK (true);
	-- VolunteerCohorts: Only authenticated users can read and write
	CREATE POLICY "select_volunteercohorts_authenticated" ON "public"."VolunteerCohorts"
	FOR SELECT TO authenticated
	USING (true);
	CREATE POLICY "modify_volunteercohorts_authenticated" ON "public"."VolunteerCohorts"
	FOR ALL TO authenticated
	USING (true) WITH CHECK (true);
	-- VolunteerRoles: Only authenticated users can read and write
	CREATE POLICY "select_volunteerroles_authenticated" ON "public"."VolunteerRoles"
	FOR SELECT TO authenticated
	USING (true);
	CREATE POLICY "modify_volunteerroles_authenticated" ON "public"."VolunteerRoles"
	FOR ALL TO authenticated
	USING (true) WITH CHECK (true);
	-- Volunteers: Only authenticated users can read and write
	CREATE POLICY "select_volunteers_authenticated" ON "public"."Volunteers"
	FOR SELECT TO authenticated
	USING (true);
	CREATE POLICY "modify_volunteers_authenticated" ON "public"."Volunteers"
	FOR ALL TO authenticated
	USING (true) WITH CHECK (true);

[ch-iv]

Superseded by #64