feat(codegen): Expose `enumStyle` option from oazapfts v7.3.0

[Suto-Michimasa]

Summary

Expose the new enumStyle option from oazapfts v7.3.0 in @rtk-query/codegen-openapi to allow users to generate as const objects for enums.

Background

oazapfts v7.3.0 (released Feb 13, 2026) added a new enumStyle option that provides three enum generation modes:

• 'union' (default) - Union types: type Status = 'active' | 'inactive'
• 'enum' - TypeScript enums: enum Status { Active = 'active' }
• 'as-const' - Const objects with companion types:

  const Status = { Active: 'active', Inactive: 'inactive' } as const;
  type Status = typeof Status[keyof typeof Status];

I implemented this feature and it was released as oazapfts v7.3.0: oazapfts/oazapfts#823

Current Behavior

@rtk-query/codegen-openapi currently only exposes the deprecated useEnumType: boolean option, which maps to:

• useEnumType: false → union types
• useEnumType: true → TypeScript enums

Desired Behavior

Add support for the enumStyle option in the codegen configuration:

const config: ConfigFile = {
  schemaFile: './openapi.json',
  apiFile: './src/store/emptyApi.ts',
  outputFile: './src/store/api.ts',
  enumStyle: 'as-const', // NEW: 'union' | 'enum' | 'as-const'
};

Motivation

as const objects are preferred over TypeScript enums in modern TypeScript projects because they offer:

• Tree-shaking: Only used values are bundled
• Smaller runtime output: No IIFE wrapper in transpiled code
• isolatedModules compatibility: Works with Vite, esbuild, SWC, etc.
• Object utilities: Object.values(), Object.keys() work naturally
• Literal type inference: More precise types

Reference: TypeScript Handbook - Objects vs Enums

Proposed Changes

1. Update oazapfts dependency to ^7.3.0
2. Add enumStyle to ConfigFile type
3. Pass enumStyle to oazapfts when generating code
4. Keep useEnumType for backward compatibility (oazapfts handles deprecation internally)

Related

• oazapfts implementation: oazapfts/oazapfts#823
• oazapfts release: oazapfts v7.3.0
• Original RTK Query enum issue: #1889

I'm happy to contribute a PR for this.

[markerikson]

Sure, please do!

[Suto-Michimasa]

OK, I'll try!!