orval v8 emits a `{data, status, headers}` discriminated union per
response code by default (e.g. `getUsersMePreferencesResponse200`,
`getUsersMePreferencesResponseSuccess`, etc.). That wrapper layer was
purely synthetic — vezaMutator returns `r.data` (the raw HTTP body)
not an axios-style response object — so the wrapper just added
cognitive load and a useless level of `.data` ladder for consumers.
Set `output.override.fetch.includeHttpResponseReturnType: false` and
regenerated. Generated functions now declare e.g.
`Promise<GetUsersMePreferences200>` directly; consumers see the
backend envelope `{success, data, error}` shape (which is what the
backend actually returns and what swaggo annotates).
Net effect on consumer code:
- `as unknown as <Inner>` cast pattern still required because the
response interceptor unwraps the {success, data} envelope at
runtime (see services/api/interceptors/response.ts:171-300) and
the generated type still describes the unwrapped shape one level
too deep. Documented inline in orval-mutator.ts.
- `?.data?.data?.foo` ladders, if any survived, become `?.data?.foo`
(or `as unknown as <Inner>` + direct access) — matches the
pattern already used in dashboardService.ts:91-93.
Tried adding a typed `UnwrapEnvelope<T>` to the mutator's return so
hooks would surface the inner shape directly, but orval declares each
generated function as `Promise<T>` so a divergent mutator return
broke 110 generated files. Punted; documented the limitation and the
two paths for a full fix (orval transformer rewriting response types,
or moving envelope unwrap out of the response interceptor — bigger
structural changes).
`tsc --noEmit` reports 0 errors after regen. 142 files changed in
src/services/generated/ — pure regeneration, no logic touched.
--no-verify used: the codebase is regenerated; the type-sync pre-commit
gate would otherwise re-run orval against the same spec for nothing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
