onSuccess(data) not typed correctly

[damien-schneider]

Describe the bug
When using onSettled, onSuccess, etc The behaviour of react query is to type the data in the params, for now it seems only the variables param is typed, the data isn't (see screenshot)

To Reproduce

Create a double mutation with onSuccess behaviour.
Use the data of the first query in the second one, using the data, you'll normally see that the data is type as any[] instead of the query data which is normally handled by react query

const { mutateAsync: insertNewTeamMember } = useInsertMutation(
    createClient().from("teams_members"),
    ["id_user", "id_team", "permission"],
    "id_user, id_team, permission",
  );

  const { mutateAsync: insertNewTeam } = useInsertMutation(
    createClient().from("teams"),
    ["id_owner", "name", "id"],
    "id, name, id_owner",
  );

  const handleInsertNewPersonnalTeam = async () => {
    if (!dataSession?.userId) {
      return null;
    }

    insertNewTeam([{ id_owner: dataSession.userId, name: "Main Team" }], {
      // --------- data is not typed here, but variables is well typed ---------//
      onSuccess: (data, variables) => {
        if (!variables[0].id_owner) {
          throw new Error("No user id");
        }
        //@ts-ignore
        if (!data[0].id) {
          throw new Error("No team id");
        }
        //@ts-ignore
        insertNewTeamMember([
          {
            id_user: variables[0].id_owner,
            //@ts-ignore
            id_team: data[0].id,
            permission: "full_access",
          },
        ]);
      },
    });
  };

Expected behavior
Should pass the type of the query

Additional context
Add any other context about the problem here.

[damien-schneider]

I just add a little more detailed, I've discovered that this is even outside the onSuccess, when I do :

const { mutateAsync: insertNewTeam } = useInsertMutation(...)

const data = await insertNewTeam(...)
// data has the following type:
// data: any[] | null

[psteinroe]

Hey @damien-schneider, thanks for reporting! Can you share the version of cache helpers, supabase cli and all supabase packages?

[damien-schneider]

Yes of course, sorry, here are the versions used :

"@tanstack/react-query": "^5.59.16",
"@supabase-cache-helpers/postgrest-react-query": "^1.10.1",
"@supabase/postgrest-js": "^1.16.3",
"@supabase/realtime-js": "^2.10.7",
"@supabase/ssr": "^0.1.0",
"@supabase/supabase-js": "^2.45.6",
"supabase": "^1.207.9",

Do you have the types working with other dependencies versions?

[damien-schneider]

@psteinroe It seems you are using SWR instead of React Query. Is the useInsertMutation hook typed with the SWR package? This will help determine whether the errors originate from the React Query package or perhaps from the core itself.

[psteinroe]

hey @damien-schneider, just checked the tests in this repo and the types are working there for the onSuccess handlers of react query. can you provide a repro? or repro it in this repo?

[damien-schneider]

Thanks for your response!

I tried reproducing the issue in this repository but couldn’t replicate it here, despite using the same versions of postgrest-js. However, I’m still encountering the error in my main project. (I'll do my best to investigate this..)

Additionally, I noticed another issue when trying to upgrade the postgrest-js version. Specifically, the problems start when upgrading beyond v1.16.1. For example, upgrading to v1.17.0 introduces type errors throughout the code:

I’ve created a branch to investigate this further, but I haven’t found a solution yet:

Branch link: fix-@supabase/postgrest-js-upgrade-to-1.17

One example of the type errors is an issue with insert mutations, where we see:

The types returned by 'select(...).select(...).single()' are incompatible between these versions.

It appears there are breaking changes in v1.17.0: Release notes.

Also, this new version is being automatically included when using @supabase/supabase-js version 2.45.4 or higher.

[damien-schneider]

Spent a lot of time trying to solve this but can't find where is the difference between this repo and mine, I found no difference but still have this raw type on my repo :

I will soon try to repplicate this error in an independant repo

[damien-schneider]

I've created a reproduction, with the database.type of the postgrest-react-query.

https://stackblitz.com/edit/stackblitz-starters-jtuadg?file=app%2Fpage.tsx

Tell me if you have difficulties opening the repro

[psteinroe]

hey @damien-schneider, thanks for investigating! I think this is because of the postgrest-js version. I am still using

		"@supabase/postgrest-js": "1.9.0",

in my project. I need to upgrade the types to work with latest postgrest-js.

[damien-schneider]

Thanks for looking into this! Since I’m new to the repo, this migration might be a bit complex for me, but let me know if there’s anything specific I can help with!

[damien-schneider]

@psteinroe

I’ve spent about an hour trying to get the types working correctly with mutations, but I haven’t had any success. Do you have a repository where this is functioning properly?
If so, could you share the versions of the packages you’re using?

I even tried using postgrest-swr, but couldn’t get the data types to work correctly, despite making some modifications to the packages. Any guidance would be greatly appreciated!

[psteinroe]

hey @damien-schneider, sorry to hear that!

can you make sure you are using the latest supabase cli version 1.223.10, regenerate the types, and then use the latest supabase-js version 2.46.1? If you need postgrest types, install the version currently in the supabase-js manifest:

    "@supabase/postgrest-js": "1.16.3",

[damien-schneider]

I'm encountering issues with type generation using the following dependencies:

• "supabase": "^1.223.10"
• "@supabase/supabase-js": "2.46.1"

Steps I've Tried:

1. PostgREST Installation:

   • Installed postgrest-js version 1.16.3.
   • Tried not installing postgrest-js at all.
   • Result: No resolution to the type issues.

2. TypeScript Setup:

   • Created a reproduction on StackBlitz using react-query and swr.
   • Result: Still facing the same type problems.

Additional Observations:

• Supabase Cache Helper Repo:
  • Unable to reproduce the type error within the supabase-cache-helper repository.
  • The type errors only occur when building the package and using it in another repository.

Summary

Despite trying different versions of postgrest-js and setting up a StackBlitz reproduction with react-query and swr, I'm still unable to resolve the type generation issues.

But, the type errors don't appear within the supabase-cache-helper repo itself but emerge only after building and integrating it into another project, I still trying to find why but for now I have no ideas.

[damien-schneider]

If someone have the types working correctly in a repo, whatever if it is swr or react-query I would love to have the version where it works, so that I can try to understand where the problem comes from

[psteinroe]

can you share your tsconfig?

[damien-schneider]

can you share your tsconfig?

In the stackblitz (here: https://stackblitz.com/edit/stackblitz-starters-jtuadg?file=app%2Fpage.tsx) this is the tsconfig :

tsconfig.json

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}

[psteinroe]

hey @damien-schneider, I dont have the time right now to debug this but I noticed you have neither swr nor react query installed? these are required as a peer dependency.

[damien-schneider]

I temporarily removed it for some tests, but it was, of course, installed initially.

I understand you don't have the time to debug this right now, but since you're likely using the library and it seems to be working for you, could you share the versions of the implicated packages you're using?

That information would be really helpful.

[psteinroe]

It's exactly the versions as well as the tsconfig files used in this repo.

[damien-schneider]

Okay, if it works locally, I’ll temporarily move the supabase-cache-helper into my monorepo while I investigate the issue.

[yushin-ito]

I also encountered the same problem, I solved the problem by making this change to the tsconfig.json file:

{
  "compilerOptions": {
    "moduleResolution": "node",
  }
}

https://stackblitz.com/edit/stackblitz-starters-dazcf4iy?file=app%2Fpage.tsx

[damien-schneider]

It's quite impossible to have "moduleResolution":"node" for a next.js app, it requires the "type": "module" in the package.json too which is quite impossible to migrate for a huge app.

[damien-schneider]

I've investigated the issue and discovered that setting moduleResolution to "bundler"—a common configuration in modern frameworks—causes type import errors with the react-query packages. These errors stem from type imports directly referencing paths within node_modules.

For example:

import { GetResult } from '@supabase/postgrest-js/dist/cjs/select-query-parser/result';
import {
  GenericSchema,
  GenericTable,
} from '@supabase/postgrest-js/dist/cjs/types';

When moduleResolution is set to "bundler", these type imports aren't correctly resolved, which breaks the functionality.

Proposed Solution:
It would be ideal to export the postgrest-js types directly within the supabase-cache-helper distribution. This approach would eliminate the need to import types using deep paths like @supabase/postgrest-js/dist/cjs/select-query-parser/result.

Question:
Has anyone found a way to achieve this? @psteinroe, do you have any insights on how we might implement this solution?

PS : I've also seen that in the new versions of postgrest-js it exports an unstable_GetResult which could be intersting to use in the future.