useFetch Type Safety With Multiple HTTP Method API Routes

[Gigantor2131]

Environment

---

• Operating System: Windows_NT
• Node Version: v16.16.0
• Nuxt Version: 3.0.0-rc.12
• Nitro Version: 0.6.0
• Package Manager: npm@8.13.2
• Builder: vite
• User Config: -
• Runtime Modules: -
• Build Modules: -

---

Reproduction

https://github.com/Gigantor2131/nuxt-fetch-type-safety/

type safety error is in app.vue
https://github.com/Gigantor2131/nuxt-fetch-type-safety/blob/796da921643f4502472df02513c97a560d3c02aa/app.vue#L25

Describe the bug

The type safety of useFetch breaks when an API Route has multiple HTTP Method. Example a GET and POST both on the route /api/example

Expected behavior is useFetch returns the type for the routes specified HTTP Method

Additional context

No response

Logs

No response

[david8z]

Working on this one 👍

[david8z]

Hi @danielroe this was already fixed in nitro, right?

What could I do to bring it to nuxt?

[danielroe]

Would you confirm whether it's fixed in the edge channel, which is using the latest nitro? https://nuxt.com/docs/guide/going-further/edge-channel/

[david8z]

Looks like the issue persists @danielroe

It looks like the issue has changed:

Nuxt 3 - RC 12	Nuxt Edge

Will create a new PR on Nitro to tackle this

[danielroe]

We may simply need to make a change in Nuxt to benefit from the incoming nitro change.

[david8z]

We may simply need to make a change in Nuxt to benefit from the incoming nitro change.

Could you explain me a little bit the steps you will follow and I can try to look into it?

[dsluijk]

Hi! I made the PR to Nitro. Haven't really had the chance to also make a PR to Nuxt yet, but it was my intention. You probably need to argument the types here:

nuxt/packages/nuxt/src/app/composables/fetch.ts

Line 26 in 50e23ba

export function useFetch<

The Nitro fetch type accepts a method somewhere as a generic, and you'll basically just need to link these two parts together. I'm on the road right now, so I can't really point out any specifics, but this should get you going.

[david8z]

Looking into it thanks @dsluijk and @danielroe ❤️

[david8z]

Hi @dsluijk I couldn't get it to anywhere 😢 could you help me out a little bit.

This is the main change I did but I am totally unsure if I am going on the good direction

With this change it looks like is always trying to get the get method

[dsluijk]

Alright, this was a little more tricky to get to work than I expected initially. I hope you don't mind me stealing your work, but I think I've made it to work now. This did require an additional change in Nitro to narrow the method generic correctly, so that needs to be merged first (unjs/nitro#883). I did get my change to work locally with that change applied. The corresponding PR can be found here: #18526

[genu]

@dsluijk This may already be addressed in the above effort, but I want to point out that this issue also occurs when working with a slug style api route:

e.g.

const slug = params.slug

const { data } = useFetch(`/api/job/${slug}`) // const data: Ref<unknown>

however, if I do this:

const slug = <''>params.slug

const { data } = useFetch(`/api/job/${slug}`) // data is correctly inferred

[dsluijk]

@genu I think that's an unrelated issue, so if you feel like I think you should open a new issue for that.

But looking at your example I think that this is just the way TypeScript works. In the first example I assume params.slug has a string type, and with the template it means that the url get's the "/api/job/${string}" type. Then the route can't be inferred correctly. With your second example you give slug the explicit type of '' (empty string), meaning that the route type will be "/api/job/". This can then be inferred, as there aren't any variables in the types. Not 100% sure this is how it works, but it's my guess.