Decimal-looking x-enum-varnames emitted as numeric JS keys, breaking z.nativeEnum

[AwkEng]

Description

When an OpenAPI integer enum has x-enum-varnames whose entries look like decimal numbers (e.g. CFR section numbers like \"22.537\"), the generated TypeScript const uses unquoted decimal literals as property keys. JavaScript parses these as numeric keys, which then breaks the generated z.nativeEnum call from the zod plugin (which requires string-keyed enums).

Reproduction

Schema fragment:

```json
{
"FccPart22Section": {
"enum": [1, 2],
"type": "integer",
"x-enum-varnames": ["22.537", "22.567"]
}
}
```

Config:

```ts
import { defineConfig } from '@hey-api/openapi-ts';

export default defineConfig({
input: 'openapi.json',
output: 'src/generated',
plugins: [
{
name: '@hey-api/typescript',
enums: { enabled: true, mode: 'javascript', case: 'preserve' },
},
{ name: 'zod', compatibilityVersion: 3, definitions: true },
],
});
```

Actual output

`types.gen.ts`:

```ts
export const FccPart22Section = {
22.537: 1,
22.567: 2,
} as const;
export type FccPart22Section = typeof FccPart22Section[keyof typeof FccPart22Section];
```

`zod.gen.ts`:

```ts
export const zFccPart22Section = z.nativeEnum(FccPart22Section);
```

TypeScript error:

```
error TS2345: Argument of type '{ readonly 22.537: 1; readonly 22.567: 2; }' is not assignable to parameter of type 'EnumLike'.
Property '22.537' is incompatible with index signature.
Type 'number' is not assignable to type 'string'.
```

Expected output

Quote the keys so they're string-typed:

```ts
export const FccPart22Section = {
"22.537": 1,
"22.567": 2,
} as const;
```

That would satisfy `z.nativeEnum`'s `EnumLike` constraint and (correctly) preserve the varnames as string keys regardless of whether they look numeric.

Version

`@hey-api/openapi-ts` 0.97.3
`zod` ^4.0.0
TypeScript 6.0.2

[pullfrog]

Plan for #3941

Root Cause

@hey-api/typescript already receives the original enum member name from x-enum-varnames / x-enumNames, but JavaScript enum object emission sends it through $.prop(...). That path calls safePropName(), which currently converts numeric-looking string names with Number(name). As a result, keys like "22.537" are emitted as numeric property names, and keys like "90.20" lose information by becoming 90.2. Zod then reuses the generated TypeScript symbol, so Zod v3 emits z.nativeEnum(Foo) against an object whose keys are typed as numeric keys instead of string keys.

Implementation Plan

1. Add a regression fixture covering decimal-looking enum varnames.

Use the existing enum-names-values specs because they already exercise JavaScript enum emission across casing modes. Add a schema with string or integer enum values and x-enum-varnames such as "101.147", "90.20", and "90.35". Include at least one trailing-zero decimal to prove the runtime key is preserved and not normalized.

2. Fix property-name emission without changing enum name resolution.

Update the object property name path so numeric-looking string property names are emitted as string literal property names rather than numeric literals. The smallest likely change is in packages/openapi-ts/src/ts-dsl/utils/name.ts, changing safePropName() to preserve string input as a string literal for numeric-looking names instead of constructing new LiteralTsDsl(Number(name)). Keep identifier-shaped keys unquoted and keep already string-literal-only keys quoted. Before finalizing, check call sites of safePropName() to confirm the broader behavior is acceptable for object literals beyond enum exports.

3. Verify TypeScript enum modes remain correct.

Do not change the existing _ prefix behavior for typescript and typescript-const enum member names in packages/openapi-ts/src/plugins/@hey-api/typescript/shared/enum.ts; those modes require valid enum member identifiers. The fix should primarily affect JavaScript object enum emission and any other object-literal key emission that currently risks numeric string coercion.

4. Add Zod coverage for co-loaded TypeScript enums.

Existing Zod snapshot tests generally run the Zod plugin without @hey-api/typescript, so add a focused scenario that loads both plugins with @hey-api/typescript configured as { enums: { enabled: true, mode: 'javascript', case: 'preserve' } } and Zod definitions enabled. This should cover the downstream path where Zod v3 emits z.nativeEnum(Foo) and Zod v4 / mini emit their equivalent enum-object reuse.

5. Update snapshots.

Regenerate the affected main snapshots for JavaScript enum output. Expect numeric-looking enum object keys to become quoted, for example 100: 100 may become '100': 100, while identifier keys like foo remain unchanged. Regenerate Zod snapshots for the new co-plugin scenario.

6. Validate.

Run targeted tests first: pnpm tt -- @test/openapi-ts, pnpm tt -- @test/openapi-ts-zod-v3, and pnpm tt -- @test/openapi-ts-zod-v4. Then run pnpm ty -- @hey-api/openapi-ts or the broader pnpm typecheck if the change touches shared DSL behavior enough to warrant it. If snapshots are updated with non-watch commands, use pnpm exec vitest run --update --project <project> after the build step rather than relying on watch mode in CI.

Expected Outcome

Generated JavaScript enum objects preserve decimal-looking varnames exactly as string keys, including trailing zeros, and Zod can consume the generated enum object without EnumLike type failures. The fix also closes the silent runtime data-loss case where two varnames like "90.20" and "90.2" could collapse to the same emitted key.

Task list (4/4 completed)

• Read issue details and applicable repository instructions
• Inspect enum generation and Zod nativeEnum code paths
• Draft an actionable implementation and verification plan
• Post the plan to the issue progress comment

  ^{｜ Implement plan ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using GPT ｜ 𝕏}

[AwkEng]

Sorry, filed in the wrong repo. Tracking internally instead.

[mrlubos]

@AwkEng nothing to fix here then?

[AwkEng]

@mrlubos apologies for the premature closure — I wanted to take time to verify this was actually a bug with no reasonable workaround before reopening, rather than leave a noisy ticket open while I dug in. Reopening now with what I found.

The headline finding: this isn't just a TS-typing nuisance, it's runtime data loss in generated code.

Standalone repro: https://github.com/AwkEng/openapi-ts-decimal-varname-repro (openapi-ts 0.97.3, single openapi.json, runs in ~10 seconds).

Given a string-valued enum with decimal-looking varnames:

{ "enum": ["FM","PS","B/ILT"], "type": "string",
  "x-enum-varnames": ["101.147","90.20","90.35"] }

openapi-ts emits:

export const StringEnumWithDecimalVarnames = {
    /** 101.147 */
    101.147: 'FM',
    /** 90.20 */
    90.2: 'PS',          // <- key emitted unquoted
    /** 90.35 */
    90.35: 'B/ILT',
} as const;

At runtime:

Object.keys(StringEnumWithDecimalVarnames) === ["101.147","90.2","90.35"]

The varname "90.20" is gone — JS coerced the unquoted decimal literal to a number, dropping the trailing zero. openapi-ts already preserves the original "90.20" in the JSDoc directly above the key, so it has the right string in hand at emit time; only the key itself is unquoted. Two varnames like "90.20" and "90.2" would collide silently into one entry.

The z.nativeEnum failure from my original report is a downstream symptom of the same root cause — EnumLike requires string keys, and these keys are numeric:

src/generated/zod.gen.ts(7,57): error TS2345: Argument of type
'{ readonly 22.537: 1; readonly 22.567: 2; }' is not assignable to parameter
of type 'EnumLike'. Property '22.537' is incompatible with index signature.
Type 'number' is not assignable to type 'string'.

Workarounds considered and rejected:

• Renaming the enum members — these are CFR section numbers ("22.537", "90.20"), surfaced verbatim to end users.
• Post-generation patch script — works, but belongs upstream given the data-loss angle.

Minimal fix: quote the emitted key when the varname isn't a valid JS identifier (or unconditionally — quoted identifier-shaped keys are still legal). Possibly related: #3366 — same family of "JS number coercion in codegen loses information."

[Dharya-dev]

Hey! I ran into this same issue on a project with CFR section numbers as enum varnames and dug into the root cause.

The problem is in safePropName() in packages/openapi-ts/src/ts-dsl/utils/name.ts — it does Number(name) on any numeric-looking string, which silently drops trailing zeros (90.20 becomes 90.2). Two varnames like 90.20 and 90.2 would even collide into the same key.

I've got a fix ready that adds a String(Number(name)) !== name guard — if the conversion would lose information, it emits a quoted string literal instead. Integers and lossless decimals stay as numeric keys so there's no unnecessary churn. Opening a PR now.