fix(supabase): relax db schema type constraints in createClient options

[gourabsingha1]

This PR fixes a bug (Issue #969) where TypeScript displays a type error when attempting to initialize a client with a custom database schema under db.schema, unless the user explicitly passes the schema as the second generic parameter to createClient. Because of the lack of partial generic inference in TypeScript, when only the first generic parameter <Database> is supplied, the second generic parameter (SchemaName) defaults to 'public', restricting the type of the db.schema option to 'public'. This PR relaxes the schema option type under db to string so that initialization compiles successfully, while preserving type-safety of database/schema queries.

[mandarini]

Hi @gourabsingha1, thank you so much for contributing to Supabase! Really appreciate you digging into #969, it's a genuinely confusing error to hit.

One thing to flag before this can merge: relaxing db.schema to string removes the type checking for everyone, including the two-generic form (createClient<Database, 'personal'>(...)) where it currently works correctly and catches typos. It also doesn't fully solve the original problem, since with only createClient<Database>(...), the client's .from() calls will still be typed against public even though db.schema is set to personal at runtime. So the fix trades a compile error for a silent mismatch between the configured schema and the query types.

The good news is there's already a fully type-safe way to do this: supabase.schema('personal').from(...), which infers its type directly from the call. Would you be up for either narrowing this to only relax the type where inference genuinely can't help, or pivoting the PR toward pointing users at .schema() (docs and maybe a better error message) instead? Happy to help think through either direction.

Thank you again for taking the time to contribute, contributions like this are exactly how we find the rough edges worth smoothing out.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c3501285-332b-4738-9de4-95e4c3d9c393

📥 Commits

Reviewing files that changed from the base of the PR and between 6331898 and d4397d9.

📒 Files selected for processing (3)

• packages/core/supabase-js/src/SupabaseClient.ts
• packages/core/supabase-js/src/lib/types.ts
• packages/core/supabase-js/test/unit/SupabaseClient.test.ts

---

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Expanded database schema configuration to support custom schema names.

• Bug Fixes

  • Improved client initialization when using schemas outside the predefined schema type.

• Tests

  • Added coverage confirming clients initialize successfully with a custom schema.

Walkthrough

The db.schema option now accepts SchemaName values and arbitrary strings. SupabaseClient casts the configured schema when initializing PostgrestClient. A unit test verifies client construction with the personal schema.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gourabsingha1]

@mandarini Thanks for the feedback! I updated the type signature to use SchemaName | (string & {}). This preserves strict type checking and IDE autocompletion for SchemaName when specified, while relaxing the type to allow custom string schema names when only <Database> is supplied. Rebased onto master!