Enum values with trailing white space are trimmed

[pimveldhuisen]

Description

In OpenAPI, it is possible to define an enum type, with different string constants as its values. These string constants might contain trailing white space, or in the extreme case consist of only white space.

Example OpenAPI YAML:

FooBarCode:
  type: string
  description: "Character code to indicate the FooBar attitude"
  enum:
    - " "
    - "1"
    - "2"
    - "X"

Currently, when openapi-typescript generates types for such enums, any trailing whitespace is trimmed.

Example resulting Typescript Type with current bug:

FooBarCode: "" | "1" | "2" | "X"

Expected behaviour for resulting Typescript Type:

FooBarCode: " " | "1" | "2" | "X"

Currently, the generated type does not match the OpenAPI spec, and as a result type checking cannot be done, and in fact generates false positive errors.

Reproduction

This occurs for any enum with string values containing trailing white space.
It seems that the trimming occurs here in the code.

Resolution

If the maintainers agree that the current behaviour should be considered as a bug, I'm happy to open an MR with unit tests for this scenario and implement a fix.

Checklist

• My OpenAPI schema passes the Redocly validator (npx @redocly/cli@latest lint)
• I’m willing to open a PR (see CONTRIBUTING.md)

[drwpow]

This is a definite bug. This is also a great first issue with a straightforward problem that’s easy to write tests for.

I believe this could be captured in a schema-object.test.ts test easily, and the problem fixed within src/transform/schema-object.ts. Would happily welcome a PR on this 🙏

[mitsuyuki418]

Is this the same place? When I convert "enum": [0, 1, 2], the result is '' | 1 | 2 but I want 0 | 1 | 2
Would it be escStr(t ?? "") rather than escStr(t || "")?

[pimveldhuisen]

I opened a PR: #1269

Happy to iterate a bit if you would like to see it done differently.

I did not include any changes in the PR related to @mitsuyuki418 's comment around the 0 value, since I could not easily reproduce it. Maybe that problem is best tackled in a separate issue?

[mitsuyuki418]

sure thanks @pimveldhuisen I'll open another one for that issue :)