fix(nuxt): forward response type to ofetch options #32891
Conversation
|
|
WalkthroughThe changes update the type signatures of several TypeScript interfaces and type aliases related to fetch options in the Nuxt composables. A new generic type parameter, Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@nuxt/kit
nuxt
@nuxt/rspack-builder
@nuxt/schema
@nuxt/vite-builder
@nuxt/webpack-builder
commit: |
CodSpeed Performance ReportMerging #32891 will not alter performanceComparing Summary
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
test/fixtures/basic-types/app/app-types.ts (1)
114-122: Strengthen coverage: add inference, lazy variant, and error-hook assertionsTo guard against future regressions, consider adding:
- Inference without explicit generic (via typed route).
- The lazy variant (useLazyFetch).
- The error hook (onResponseError) which also carries response._data?: T.
Apply this diff to extend the same test:
it('works with useFetch and generic type', () => { type ApiResponse = { message: string } useFetch<ApiResponse>('/api/v1/users', { onResponse ({ response }) { expectTypeOf(response._data).toEqualTypeOf<ApiResponse | undefined>() }, }) + + // Inference from typed route (no explicit generic) + useFetch('/api/hey', { + onResponse ({ response }) { + expectTypeOf(response._data).toEqualTypeOf<{ foo: string, baz: string } | undefined>() + }, + }) + + // Lazy variant preserves the generic + useLazyFetch<ApiResponse>('/api/v1/users', { + onResponse ({ response }) { + expectTypeOf(response._data).toEqualTypeOf<ApiResponse | undefined>() + }, + }) + + // Error hook also forwards the response type + useFetch<ApiResponse>('/api/v1/users', { + onResponseError ({ response }) { + expectTypeOf(response._data).toEqualTypeOf<ApiResponse | undefined>() + }, + }) })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
test/fixtures/basic-types/app/app-types.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Follow standard TypeScript conventions and best practices
Files:
test/fixtures/basic-types/app/app-types.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: nuxt/nuxt#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T16:46:07.446Z
Learning: Applies to **/*.{ts,tsx} : Follow standard TypeScript conventions and best practices
Learnt from: TheAlexLichter
PR: nuxt/nuxt#31812
File: packages/nuxt/src/components/plugins/islands-transform.ts:202-202
Timestamp: 2025-04-18T18:33:41.753Z
Learning: In Nuxt, using `rolldownVersion` (not `rollupVersion`) is intentional when detecting if rolldown-vite is being used, even though TypeScript may show an error because the property isn't in standard type definitions yet.
📚 Learning: 2025-07-18T16:46:07.446Z
Learnt from: CR
PR: nuxt/nuxt#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T16:46:07.446Z
Learning: Applies to **/*.{test,spec}.{ts,tsx,js,jsx} : Write unit tests for core functionality using `vitest`
Applied to files:
test/fixtures/basic-types/app/app-types.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: codeql (javascript-typescript)
🔇 Additional comments (1)
test/fixtures/basic-types/app/app-types.ts (1)
117-121: Type forwarding validated for onResponseThis correctly asserts that response._data reflects the generic ApiResponse (unioned with undefined), exercising the intended fix.
2 participants
🔗 Linked issue
resolves #32890
📚 Description
Fixes typing of the
useFetchresponse hooks so thatresponse._datadoes not have theanytype, but instead inherits the generic type parameter given touseFetch.