Breaking Changes in 2.8.0 for TypeScript users?

Describe the bug It looks like that there are breaking changes in 2.8.0 for TypeScript users in useMutation:

In 2.7.1, use Mutation was typed as:

export function useMutation<TResult, TVariables = undefined, TError = Error, TSnapshot = unknown>(
  mutationFn: MutationFunction<TResult, TVariables, TError, TSnapshot>,
  mutationOptions?: MutationOptions<TResult, TVariables, TError, TSnapshot>
): MutationResultPair<TResult, TVariables, TError>

https://unpkg.com/browse/react-query@2.7.1/types/index.d.ts

Now in 2.8.0, TVariables and TError have swapped their places:

export declare function useMutation<TResult, TError = unknown, TVariables = undefined, TSnapshot = unknown(
  mutationFn: MutationFunction<TResult, TVariables>, 
  config?: MutationConfig<TResult, TError, TVariables, TSnapshot>
): MutationResultPair<TResult, TError, TVariables, TSnapshot>;

https://unpkg.com/browse/react-query@2.8.0/types/react/useMutation.d.ts

This results in TS Errors for the code which was working in 2.7.1:

return useMutation<void, { items: string[]; otherItems: string[] }>(async ({ items, otherItems }) => {
...
});

Error: TS2339: Property 'items' does not exist on type 'undefined'.

By adding e.g. any as second generic to the useMutation function everything is working as expected again.

Expected behavior I would have expected that the signature of the method didn’t change in a minor release. Anyhow, I think this is not a really big issue which would require a rollback of that change, but it should be mentioned in the release for example so that TypeScript users know how to deal with this issue.

[jackmellis]

Oh man I kinda understand your explanation but I can’t tell you how much work this has created for us!

We have react query as a peer dependency in about 20 repos, where 15 of them were written during 2.7 and the others 2.8+. Trying to use them all in a single application has caused hundreds of ts errors.

Errors that arise due to you tightening up an existing type - that’s awesome - they almost always shed light on an oversight by the consumer. But when you’re not doing breaking changes after renaming an exported type, that’s rough! In my books that’s totally a change to the public API

[tannerlinsley]

Yes, the types had breaking changes, but the public API did not. Among many other libraries, React Query does not include Types when determining semver changes. Since TypeScript is an extremely strict compilation language, any and all type changes would technically be considered breaking changes, which obviously wouldn’t work.

As a TypeScript user, you should probably have your dependencies locked down to specific patch versions x.x.patch, and not auto-resolving versions like x.x^. Otherwise, type changes would always break your code without your consent.

With that said, type changes are handled as type: or fix: semantic changes and results in new patch versions. You can and should be manually vetting and upgrading (and consequently ensuring type safety throughout) your application when you upgrade dependencies in TypeScript.