[BUG][typescript] String enum values containing "/*" are corrupted to "/_*"

[dorakemon]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

When a string enum value contains the sequence /* (e.g. a wildcard pattern like foo/*), the generated value is silently corrupted to foo/_*, so the client-side constant no longer matches the value the server actually uses.

The cause is that AbstractTypeScriptClientCodegen.toEnumValue() runs the value through escapeText(), which applies escapeUnsafeCharacters():

// AbstractTypeScriptClientCodegen.java
@Override
public String escapeUnsafeCharacters(String input) {
    return input.replace("*/", "*_/").replace("/*", "/_*");
}

This rewrite protects text interpolated into block comments, but enum values are only emitted inside a string literal, where /* is harmless. Since templates receive the already-escaped value (there is no unescapedValue), this cannot be worked around with a custom template.

openapi-generator version

Reproduced with 7.3.0 and 7.17.0. Not a regression — escapeUnsafeCharacters is unchanged on current master.

OpenAPI declaration file content or url

openapi: 3.0.3
info:
  title: repro
  version: 1.0.0
paths: {}
components:
  schemas:
    Pattern:
      type: string
      enum:
        - "foo/*"

Generation Details

openapi-generator-cli generate -i spec.yaml -g typescript-fetch -o out

Steps to reproduce

Generate a client from the spec above and inspect out/models/Pattern.ts.

Actual:

export const Pattern = {
    Foo: 'foo/_*'
} as const;

Expected:

export const Pattern = {
    Foo: 'foo/*'
} as const;

Related issues/PRs

#23962 discusses the underlying design issue: escaping is applied while building the template data model, before the rendering context (comment vs. string literal) is known.

Suggest a fix

toEnumValue() should apply only string-literal-safe escaping (quotes, backslashes, newlines), leaving comment escaping to interpolation sites that are actually inside comments. Other generators share the same toEnumValue() → escapeText() chain, so this is likely not limited to the TypeScript family, though I have only verified typescript-fetch.

[adityaanikam]

Confirmed against current master — toEnumValue() calls escapeText(value), which chains into escapeUnsafeCharacters():

@Override
public String escapeUnsafeCharacters(String input) {
    return input.replace("*/", "*_/").replace("/*", "/_*");
}

This is comment-delimiter escaping applied unconditionally, even though toEnumValue() only ever emits the value inside a string literal ("'" + escapeText(value) + "'"), never inside a comment. Agreed with your read on #23962 — this is the general design issue (escaping decided before the rendering context is known) surfacing concretely here.

I'd like to work on this: scope toEnumValue() to string-literal-safe escaping only (quotes, backslashes, newlines) rather than routing through the comment-safe escapeText() path. Since you flagged other generators share this same toEnumValue() → escapeText() chain, I'll check whether the fix belongs in the shared base or needs to stay TypeScript-specific to avoid changing behavior for generators that legitimately interpolate enum values into comments somewhere.