supabase/supabase-js

@supabase/supabase-js v2.50.4 breaks types

Closed this issue · 5 comments

ElectricCodeGuy commented

Bug report

Describe the bug

After upgrading to @supabase/supabase-js v2.50.4, TypeScript throws type compatibility errors when using SupabaseClient with generated Database types. The error indicates that the generic type parameters for SupabaseClient are incompatible with the new __InternalSupabase metadata in generated Database types.

To Reproduce

  1. Upgrade to @supabase/supabase-js v2.50.4
  2. Generate database types using Supabase CLI (which includes the new __InternalSupabase metadata)
  3. Use createServerClient or any function that expects a SupabaseClient<Database> type
  4. TypeScript error occurs:
Argument of type 'SupabaseClient<Database, "public", { Tables: { ... }>' is not assignable to parameter of type 'SupabaseClient<Database, { PostgrestVersion: "12"; }, "public", { Tables: { ... }>'
Type 'string' is not assignable to type '{ PostgrestVersion: "12"; }'

Code snippets:

Generated Database type (new in v2.50.4):

export type Database = {
  // Allows to automatically instanciate createClient with right options
  // instead of createClient<Database, { PostgrestVersion: 'XX' }>(URL, KEY)
  __InternalSupabase: {
    PostgrestVersion: '12.2.3 (519615d)';
  };
  public: {
    Tables: {
      // ... table definitions
    }
  }
}

Function signature that fails:

async function getUserSavedDocuments(
  supabase: SupabaseClient<Database>
) {
  // Function body
}

Client creation:

import { createServerClient } from '@supabase/ssr';

export const createServerSupabaseClient = async () => {
  return createServerClient<Database>(supabaseUrl, supabaseKey, {
    cookies: { /* cookie config */ }
  });
};

Expected behavior

The SupabaseClient types should be compatible with the new __InternalSupabase metadata in Database types, or the type inference should automatically handle the PostgrestVersion from the __InternalSupabase field without requiring manual specification.

System information

  • OS: Linux
  • Browser: N/A (Node.js/Next.js application)
  • Version of supabase-js: v2.50.4 (latest)
  • Version of Node.js: 22+
  • Framework: Next.js with App Router v15

Additional context

  • Workaround: Downgrading to a previous version (before v2.50.4) resolves the issue
  • Breaking change: This appears to be an unintentional breaking change introduced in v2.50.4
  • Root cause: Not sure
  • Impact: Affects all TypeScript users using generated database types with the latest Supabase version

This is the 5 or 6'th breaking change in a row that should not happen... Please this is getting super annoying

harrybawsac commented

Everything is of type any now. Also, all relationships are of array type suddenly.

const something: {
    id: any;
    user_id: any;
    some: any;
    thing: any;
    exchanges: {
        name: any;
        url: any;
        test_url: any;
    }[];
    is_test: any;
}[]
avallete commented

Hey, thanks a lot for raising the alarm on this it was indeed an unexpected breaking change affecting supabase-js when used as peer-dependency of the @supabase/ssr packages. We've reverted the change in v2.50.5, so updating to that version should restore compatibility.

We fully agree that breaking changes like this shouldn't go undetected. We're actively strengthening our CI to test against a broader set of environments and setups and we'll definitely be adding another one thanks to this issue and aiming to do better.

Also @harrybawsac just to clarify, is the any typing and array relationships issue you had also happening with the use of @supabase/ssr package too, or in a different setup? And were the database types recently regenerated ?

We're really sorry for the trouble this caused and truly appreciate everyone's patience and detailed reports as we work to make things right.

  • ❤️7
harrybawsac commented

You are the best. I upgraded to v2.50.5 and ran the type generator. Everything just works again. Relations that have a single entity no longer come back as an array, but as a single. Everything is typed again (instead of all being any).

Thanks!

Edit to come back to your questions:

  • Yeah, I do use the @supabase/ssr (v0.6.1) package in my project.
  • I generated the types earlier today after updating to v2.50.4 and gave me the any stuff.
2Senn commented

I am still getting this type error after upgrading:

Property 'supabaseUrl' is protected but type 'SupabaseClient<Database, SchemaName, Schema>' is not a class derived from 'SupabaseClient<Database, SchemaName, Schema>'.ts

Not sure if this is happening to anyone else.

I am using 2.50.4 for supabase-js and 0.6.1 for ssr

harrybawsac commented

@2Senn Please update to at least v2.50.5.