[Bug] serverSupabaseClient returns 'any' type instead of inferred Database types in Nuxt 4.1.2

[rasyidly]

In nuxt-supabase v2.0.0 with Nuxt 4.1.2, serverSupabaseClient is returning any type on the client-side instead of the proper inferred types from the generated Database types. This happens even though the Supabase config specifies the types path, and the documentation claims auto-discovery.

However, explicitly adding <Database> to serverSupabaseClient<Database>() fixes it. Why is the generic type not auto-discovered as per the docs?

To Reproduce

1. Set up a Nuxt 4.1.2 project with nuxt-supabase v2.0.0.
2. Configure Supabase in nuxt.config.ts:

   supabase: {
     types: '~~/types/database.types.ts'
   }
   

3. Create a server route like this (e.g., server/api/test.post.ts):

   import { useValidatedBody, z } from 'h3-zod'
   import { serverSupabaseClient, serverSupabaseUser } from '#supabase/server'
   
   export default defineEventHandler(async (event) => {
     const user = await serverSupabaseUser(event)
     if (!user) {
       throw createError({ statusCode: 401, statusMessage: 'Unauthorized' })
     }
   
     const body = await useValidatedBody(event, z.object({
       ...
     }))
   
     const supabase = await serverSupabaseClient(event)
   
     // Calculate total amount
     const totalAmount = body.items.reduce((total: number, item: { qty: number, price: number }) => {
       return total + (item.qty * item.price)
     }, 0)
   
     // Insert to Supabase
     const { data, error } = await supabase
       .schema('finance')
       .from('budgets')
       .insert({
         title: body.title,
         total_amount: totalAmount,
         ...
       })
       .select()
       .single()
   
     if (error) {
       throw createError({
         statusCode: 500,
         statusMessage: error.message || 'Failed to create budget planning'
       })
     }
   
     return data
   })
   

4. Call this route from the client-side using useFetch or $fetch.
5. Observe the return type in your IDE or TypeScript checker: FetchResult<'/api/test', 'POST'> returns any instead of the expected infering query result.

Expected behavior

The client-side should infer the correct Database types (e.g., from database.types.ts) without needing to explicitly specify <Database>. As per the docs: "The database definitions will be automatically passed to all clients: useSupabaseClient, serverSupabaseClient and serverSupabaseServiceRole."

Actual behavior

• Without <Database>, the return type is any.
• With serverSupabaseClient<Database>(), it works correctly.
• When returning a simple string like 'test', the type is correctly inferred as string.

Screenshots

• Server route code:
• Client-side result:

Environment

• Nuxt version: 4.1.2
• nuxt-supabase version: 2.0.0
• Node.js version: v23.9.0
• Operating System: macOS

Additional context

This seems like a TypeScript inference issue in the module. The workaround is to manually add <Database>, but it should be automatic as documented.

[larbish]

Hey @rasyidly, logs have been added in the latest release if your database types file is not detected. Can you try with v2.0.1 and confirm the logs are not displayed (thus types are detected) but it's still not inferring in your project?

[rasyidly]

I've created a reproduction repo for this type inference issue. On the server side, type inference works correctly for Supabase queries, but when using FetchResult on the client, it returns any instead of the properly typed response.

Here the reproduction repo

Key files to check:

• getPosts.get.ts (server-side inference works)
• years.vue (client-side FetchResult fails to infer types)
• database.types.ts (generated Supabase types) - You need to run supabase gen

The issue seems to be that FetchResult can't properly infer types from API routes that return data directly from Supabase queries, even though the server-side code has correct typing.

[rasyidly]

any news?

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.