typed-openapi@2.2.3

Patch Changes

• c40f9ad: Fix recursive record type generation

typed-openapi@2.2.2

Patch Changes

• b564cd5: chore(BREAKING): rm tanstack local withResponse option cause useMutation cant infer the generics passed at
  this point so it doesnt have any effect on the output type (it works at runtime but desynchronized with its typing)

  chore: rename TypedResponseError -> TypedStatusError (happens on expected error status code) to distinguish it better
  from TypedErrorResponse

typed-openapi@2.2.1

Patch Changes

• e8526b5: fix: tanstack inference in some edge cases

typed-openapi@2.2.0

Minor Changes

• 04a41a6: feat: allow specifying overrides on any request fix: infer/narrow response with multiple json media types
  fix: properly handle mutation errors while retaining genericity on output based on mutationFn withResponse: true/false
  feat: decodePathParams/encodeSearchParams/parseResponseData feat: allow passing overrides/withResponse even if there's
  no endpoint parameters

typed-openapi@2.1.2

Patch Changes

• 057e156: Fix type inference on success calls when not using withResponse: true while having multiple responses (ex:
  one for status 200 and another or status 304) with one that has a resulting schema of unknown

typed-openapi@2.1.1

Patch Changes

• 2923a0f: Fix responseHeaders generation by inlining the type instead of referencing it.

typed-openapi@2.1.0

Minor Changes

• 213f6ee: fix: make a union of multiple responses on the same status code (due to different media types)

  refactor: remove Endpoint["response"] arbitrarly choosen "main" response in favor of listing all possible success code

  refactor: responseHeaders now uses a Record<StatusCode, Headers> instead of simply being the typed headers of the
  "main" response feat: TypedHeaders

  refactor: rename+export success/error interfaces

typed-openapi@2.0.2

Patch Changes

• f1f0e89: Allow any response type with media type containing application + json

typed-openapi@2.0.1

Patch Changes

• e1de70a: Fix Schemas namespace missing for schema refs within parameter arrays #51
  #51
• 47243f1: Accept any response content type of '/' as successful response
  #52
• abbab94: fix: Wrong codegen for additionalProperties #57 #57
• 8a4c6c9: - New CLI option allow generating a fetcher and a standalone API client file (matching the example in
  api-client.example.ts).
  • Output paths for both the TanStack Query client and default fetcher can now be absolute or relative.
  • The standalone API client filename is configurable (defaults to api.client.ts). -> This makes it easier to start
    using the generated API clients

typed-openapi@2.0.0

Major Changes

• 8f1eaa5: Add comprehensive type-safe error handling and configurable status codes

  • Type-safe error handling: Added discriminated unions for API responses with SafeApiResponse and
    InferResponseByStatus types that distinguish between success and error responses based on HTTP status codes
  • TypedResponseError class: Introduced TypedResponseError that extends the native Error class to include typed
    response data for easier error handling
  • Expose successStatusCodes and errorStatusCodes arrays on the generated API client instance for runtime access
  • withResponse parameter: Enhanced API clients to optionally return both the parsed data and the original Response
    object for advanced use cases
  • throwOnStatusError option: Added throwOnStatusError option to automatically throw TypedResponseError for
    error status codes, simplifying error handling in async/await patterns, defaulting to true (unless withResponse
    is set to true)
  • TanStack Query integration: The above features are fully integrated into the TanStack Query client generator:
    • Advanced mutation options supporting withResponse and selectFn parameters
    • Automatic error type inference based on OpenAPI error schemas instead of generic Error type
    • Type-safe error handling with discriminated unions for mutations
    • Response-like error objects that extend Response with additional data property for consistency
  • Configurable status codes: Made success and error status codes fully configurable:
    • New --success-status-codes and --error-status-codes CLI options
    • GeneratorOptions now accepts successStatusCodes and errorStatusCodes arrays
    • Default error status codes cover comprehensive 4xx and 5xx ranges
  • Enhanced CLI options: Added new command-line options for better control:
    • --include-client to control whether to generate API client types and implementation
    • --include-client=false to only generate the schemas and endpoints
  • Enhanced types: expose SuccessStatusCode / ErrorStatusCode type and their matching runtime typed arrays
  • Comprehensive documentation: Added detailed examples and guides for error handling patterns

  This release significantly improves the type safety and flexibility of generated API clients, especially for error
  handling scenarios.