Does this still type hint/constrain the result of this function? If not we might as well return any.

Nice catch, there's no type constrain any more, I've applied you suggestion to return any, thanks!

Ideally we'd like it to constrain the return, I think.

I guess the issue is that the type of nuxtApp.payload[key] is unknown and ideally when using the function we should either assert that this type matches or perform some sanitisation to ensure it matches. (We might exempt unknown given that this is likely a common situation.)

Agreed, I think constrain and type hint really matters.

I just found the type of data will be influenced by the return of getCachedData, for example

Here the type of data is Ref<boolean | null>

const { data } = await useAsyncData("test2", async () => ({ hello: "world!" }), {
  getCachedData: (key) => {
    return true
  },
});

The cache useNuxtApp().payload.data[key] is any, which caused an any data. As of that, I think users should handle the return type of getCachedData if it's any.

Wouldn't this be a great usecase for the new NoInfer type utility? This would make getCachedData not influence the type of data, but still give hints/constrain the type of getCachedData.
e.g.

type AsyncDataOptions<...> = {
    getCachedData?: (key: string) => NoInfer<DataT>;
}

As it's a rather new feature (TS 5.4), we might reimplement it like so for now:

// see https://github.com/millsp/ts-toolbelt/blob/master/sources/Function/NoInfer.ts
type NoInfer<T> = [T][T extends any ? 0 : never];

what a great idea!

Thanks @94726, I've applied your suggestion, it looks good!