supabase / supabase-js

An isomorphic Javascript client for Supabase. Query your Supabase database, subscribe to realtime events, upload and download files, browse typescript examples, invoke postgres functions via rpc, invoke supabase edge functions, query pgvector.
https://supabase.com
MIT License
2.83k stars 219 forks source link

ParserError on return type with aggregate functions #1000

Open DuncanLHS opened 1 month ago

DuncanLHS commented 1 month ago

Bug report

Describe the bug

There appears to be a problem with the return TS types when using aggregate functions and referenced tables. Instead of getting the expected return type, I'm getting ParserError<'error'>

Example with my function (I believe this is correct and it does run successfully):

export async function getAllProjectsSummary(request: Request) {
  const { supabase } = createSupabaseServerClient({ request });
  const { data, error } = await supabase.from("projects").select(
    "project_no, project_name, project_media(count()), documents(count())",
  );
  if (error) {
    return { error: error.message };
  }
  return data;
}

The data return type here is ParserError<"Expected identifier at `)), documents(count())`">[]

To Reproduce

  1. Create 2 tables with a one-to-many relationship between the first and second.
  2. Run a select postgREST query on table 1 including including an aggregate function on related columns in table 2

Expected behavior

Expected data return type to reflect the query.

i.e.

data: {
    project_no: string;
    project_name: string;
    project_media: {
        count: {}[];
    }[];
    documents: {
        count: {}[];
    }[];
}[]

System information

Additional context

Interestingly using count(*) or count('*') generates the correct return type so it would appear the query builder just isn't handling the brackets correctly for aggregate functions and is expecting something between them as it would for referenced tables. These of course generate an error as they're incorrect syntax for the count function.

A very quick check on a simpler query seems to yield the same error even without referencing related tables.

DuncanLHS commented 1 month ago

Appears to have been fixed in postgrest-js v1.13. Dependency needs updating here.