feat(plugin-axios,plugin-fetch): add unwrap() to every generated call - #820
Conversation
kubb-labs/discussions#3952 asked for a way to get a generated call's
success body without destructuring { data } at every call site.
Rather than a plugin-wide returnType default (see PR #818), take the
Redux-Toolkit approach: every call's promise gains an unwrap() method,
resolving to the bare success body or rejecting with `error`. Plain
`await getPetById(...)` keeps returning the full result, so existing
code and the query plugins (react-query, vue-query, swr, mcp) are
unaffected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012DSVW79h2FdFDkoWWr6PwN
Review or Edit in CodeSandboxOpen the branch in Web Editor • VS Code • Insiders |
🦋 Changeset detectedLatest commit: 5264b05 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
More templates
@kubb/plugin-axios
@kubb/plugin-cypress
@kubb/plugin-faker
@kubb/plugin-fetch
@kubb/plugin-mcp
@kubb/plugin-msw
@kubb/plugin-react-query
@kubb/plugin-redoc
@kubb/plugin-swr
@kubb/plugin-ts
@kubb/plugin-vue-query
@kubb/plugin-zod
commit: |
|
Size Change: +764 B (+0.25%) Total Size: 312 kB 📦 View Changed
ℹ️ View Unchanged
|
… in withUnwrap CI caught this on this repo's own examples/axios: an operation with no documented 2xx response (deletePet, 400 only) failed to typecheck. withUnwrap(request(callConfig)) inferred its generic from the client's own CallResult type, so the outer `as Unwrappable<RequestResult<...>>` cast carried two incompatible `.then` overloads and TypeScript rejected it as too narrow a conversion. Casting the call to RequestResult first, then wrapping, keeps withUnwrap's generic inferred as RequestResult directly, matching what the code did before this feature and avoiding the second cast entirely. Reproduced the exact failure in isolation, confirmed the fix, then verified end-to-end with a real `pnpm generate` against a built plugin-axios (this sandbox has no prebuilt dist, so pnpm generate otherwise fails to resolve the plugin). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012DSVW79h2FdFDkoWWr6PwN
📄 Knowledge review🆕 New pages1 new page was drafted from this PR.
|
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012DSVW79h2FdFDkoWWr6PwN
…a shared runtime helper /simplify's reuse, simplification, and altitude passes all converged on the same finding: the generated return statement inlined `config.throwOnError ?? true ? result.data : result` as a literal string, restating a default the runtime already applies internally, once per operation across every spec. The sibling `text/event-stream` path already centralizes its post-processing in a runtime function (toEventStream); this does the same for returnType: 'data' with a new unwrapResult(promise, throwOnError) exported from both templates. Verified with a real `pnpm generate` against a built plugin-axios, covering the no-2xx-response edge case that broke CI on PR #820. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012DSVW79h2FdFDkoWWr6PwN
/simplify: withUnwrap is a pure function over a promise, so most of its tests don't need the axios/fetch client mocking machinery. Call it directly with a resolved/rejected promise instead. The one case that genuinely exercised the client (rejection propagation) is simplified to a plain rejected promise, since that's standard Promise behavior withUnwrap doesn't special-case. Also reviewed the diff for reuse, efficiency, and altitude issues (three of four /simplify agents hit a rate limit and had to be redone by hand): no other findings. A suggested "UnwrapResult duplicates SuccessOf" reuse finding was a false positive — they operate on different type shapes (the OpenAPI responses record vs. the resolved RequestResult union) and can't share an implementation without coupling withUnwrap's generic to spec-shape information it doesn't need. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012DSVW79h2FdFDkoWWr6PwN
◈ PR Lens
Architecture 
7 components touched across 5 lanes. Inside the changed components — 3 viewsComponent view — Internals Client Builder Internal modules in @internals/client building unwrappable function signatures, return statements, and SDK class methods. 
Component view — Fetch Plugin Runtime The fetch client plugin modules, runtime template with withUnwrap and Unwrappable types, and request serializers. 
Component view — Axios Plugin Runtime The Axios client plugin modules, runtime template with withUnwrap and Unwrappable types, and request serializers. 
Data flow 
The other flows — 1 sequence
Drill down
|
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
…) in generated hooks
Query and mutation bodies destructured `{ data }` off the client call by hand. Every axios/fetch
call already carries unwrap(), so the generated hooks call it directly instead, one line shorter
and consistent with how a caller reaches for the bare success body outside a hook.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012DSVW79h2FdFDkoWWr6PwN
2 participants
🎯 Changes
An alternative to the
returnTypeoption in #818, requested in kubb-labs/discussions#3952: a way to get a generated call's success body without destructuring{ data }at every call site.This takes the Redux Toolkit approach instead of a plugin-wide default. Every generated call (standalone function or SDK method) now resolves to a promise with an extra
unwrap()method.unwrap()resolves to the bare success body, or rejects witherrorfor a result that carried one (only reachable withthrowOnError: false, since the throwing path never resolves an error).await getPetById(...)still resolves to the full{ status, data, error, contentType, request, response }result, exactly as before. There's no option to turn this on or off, it's just there. That also means it composes cleanly with the query plugins:@kubb/plugin-react-query,@kubb/plugin-vue-query,@kubb/plugin-swr, and@kubb/plugin-mcpall call the generated client directly andawaitit, so their generated hooks are byte-for-byte unchanged.Built independently of #818's
returnTypeoption (this branch is offmain, not stacked on it), so the two designs can be reviewed and land separately.How it works
plugin-axios/plugin-fetchruntime templates (templates/*.ts) addUnwrapResult,Unwrappable, and awithUnwrap()helper that attaches.unwrap()to a call's result promise.internals/client:buildResultTypenow always wrapsRequestResultinUnwrappable, andbuildReturnStatementwraps every call inwithUnwrap(...). Both the standalone functions and the class-based SDK pick this up automatically.tests/3.0.xe2e snapshot and package-level generator snapshot that embeds a generated operation or.kubb/client.tswas regenerated. I checked the diff by hand: it's mechanical.✅ Checklist
pnpm run test.🚀 Release Impact
🤖 Generated with Claude Code
https://claude.ai/code/session_012DSVW79h2FdFDkoWWr6PwN