feat: generate Supabase TypeScript types for typed database client

[GMetaxakis]

PR Checklist

• - Unit and/or e2e tests for the changes that have been added (for bug fixes / features)

PR Type

• Feature

What is the new behavior?

• Added src/database.types.ts with generated TypeScript types for all 26 tables, 14 RPC functions, and 6 enums
• The Supabase client in supabase.server.ts is now typed with createServerClient<Database>(...), giving compile-time checks on table names, column names, insert/update payloads, and RPC function signatures
• Added db:types script to package.json for regenerating types from a local Supabase instance (yarn db:types)
• Fixed all resulting type errors across 27 route files (Date↔string conversions, Json↔DBMedia casts, route param narrowing, enum type assertions)

Does this PR introduce a DB Schema Change or Migration?

• No

Git Issues

Closes #4344

[cypress]

onearmy-community-platform    Run #8808

Run Properties:   Passed #8808  •  5a63edd545: Merge remote-tracking branch 'origin/master' into feat/supabase-typescript-types

Project	onearmy-community-platform
Branch Review	pull/4658
Run status	Passed #8808
Run duration	06m 57s
Commit	5a63edd545: Merge remote-tracking branch 'origin/master' into feat/supabase-typescript-types
Committer	Georgios Metaxakis
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	1
Pending	0
Skipped	0
Passing	90
View all changes introduced in this branch ↗︎

[mariojsnunes]

does this still work, or fixes a bug?

[GMetaxakis]

Still works the same — the Supabase client serializes Date objects to ISO strings internally, so the runtime behavior is unchanged. The explicit .toISOString() is needed because the typed client expects string for timestamp columns, not Date.

[mariojsnunes]

I've tried this before, adding all those casts didn't feel great.

• Are there any cases where it actually improves type checking?
• Can we remove any of our DB types like DBProfile, DBComment ?

[GMetaxakis]

Good points. The main wins right now are on inserts/updates and RPC calls — those get real type checking (correct column names, enum values, etc.). The read-side casts are ugly and don't add much.

Let me give it a try to remove the DB types like DBProfile, DBComment, etc. and replace them with the generated types (Tables<'profiles'>, Tables<'comments'>). That would eliminate both the manual types and the as unknown as casts.

[GMetaxakis]

Updated the PR based on feedback. Here's what changed:

Eliminated all as unknown as casts from route files:

• Created semantic helper functions (toJson, fromJson, fromJsonArray, dbResult, dbResultArray) in src/utils/supabase.types.ts
• These centralize the type bridge between Supabase's generated types and our DB model types — the casts still exist internally but route files are clean

Converted all DB model classes to interfaces:

• DBProfile, DBNews, DBComment, DBQuestion, DBResearchItem, DBResearchUpdate, DBProject, DBProjectStep, DBCategory, DBTag, DBProfileTag, DBProfileBadge, DBProfileType, DBMedia, DBNotification, DBMapPin, DBBanner — all converted from class → interface
• Removed the fake Object.assign constructors (net -91 lines)
• Replaced new DB*() instantiation patterns with plain object literals

Moved database.types.ts to shared/:

• Generated types now live alongside DB models in the oa-shared package
• Database, Tables, Json exported from oa-shared
• This enables DB models to derive from generated Row types in the future (incremental follow-up)

Aligned DB date types with Supabase returns:

• Changed Date → string for created_at/modified_at fields across all DB types (matching what Supabase actually returns as ISO strings)

The as unknown as casts can't be fully removed without rewriting DB types to derive from Tables<'tablename'> — the structural mismatch between Supabase's Json type for jsonb columns and our structured types (DBMedia, etc.) requires a type bridge somewhere. The helper functions make this explicit and centralized rather than scattered across every route file.

[mariojsnunes]

great work! I need to look into this carefully