Fix build for missing Supabase env vars

[wiatrM]

Summary

• handle missing Supabase credentials during build
• allow blog service to skip Supabase calls when not configured
• guard auth service and context against missing Supabase
• show message in SupabaseConnectionTest when Supabase isn't configured

Testing

• npm run lint
• npm run build
• npm test
• npm run test:e2e (fails: WebServer warnings, ended manually)
• npm run test:a11y (fails: missing script)

---

https://chatgpt.com/codex/tasks/task_e_6868147445088325b02768260de8b28e

[Copilot]

Pull Request Overview

This PR introduces fallbacks and guards around missing Supabase environment variables to prevent build and runtime errors when Supabase is unconfigured.

• Provide placeholder URL/anon key and expose isSupabaseConfigured flag.
• Guard client/server creation and service methods (blog & auth) to skip Supabase calls.
• Update context and test component to handle and display missing Supabase config.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
lib/supabase/client.ts	Added placeholder env defaults, isSupabaseConfigured, and guard in createServerClient.
lib/services/blog.service.ts	Early-return branches when Supabase is unconfigured with console warnings.
lib/auth/auth.service.ts	Added config checks in each auth method and default behavior in onAuthStateChange.
contexts/AuthContext.tsx	Wraps auth-state subscription in isSupabaseConfigured check.
components/SupabaseConnectionTest.tsx	Shows error message if Supabase isn’t configured before testing.

Comments suppressed due to low confidence (2)

components/SupabaseConnectionTest.tsx:12

• We should add unit or integration tests for the branch where Supabase isn’t configured to verify that the component shows the error state as expected.

      if (!isSupabaseConfigured) {

lib/auth/auth.service.ts:224

• The fallback return of { data: null } in onAuthStateChange doesn’t include a subscription property, which consumers expect. Consider returning { data: { subscription: null } } for a consistent interface.

    if (!isSupabaseConfigured) {

[Copilot]

There's a lot of repeated if (!isSupabaseConfigured) boilerplate across service methods. Consider extracting this pattern into a higher-order function or wrapper to reduce duplication and improve readability.

[Copilot]

The non-null assertions (!) on supabaseUrl and supabaseAnonKey are redundant since they always have a fallback string value. You can remove the ! operators.

Suggested change

	return createClient<Database>(supabaseUrl!, supabaseAnonKey!)
	return createClient<Database>(supabaseUrl, supabaseAnonKey)