fix(openapi-typescript): Stringify primitive constant values

[duncanbeevers]

Closes #1118

Changes

#1118

The escStr function claims to always return a string, but in fact would return whatever was passed into it, preserving the original type.
This PR aligns the behavior of the function with type signature, and keeps the original behavior mostly the same.
Because these values were being turned into strings (through implicit toString() during backtick string expansion), the final generated output was mostly correct.
Additionally, because there was special handling for const values with a specified type, some string consts were being quoted.

In this PR, I removed the special handling of const types, and instead pass every const value through escStr.
escStr then passes non-string arguments through JSON.stringify.

How to Review

Ensure JSON stringification of primitive types is the correct treatment for OpenAPI const members, even with no type specified.

I added tests for string and number consts with both explicit and implicit type arguments.

• Where in the OpenAPI spec is const described? I couldn't find it in the 3.1 spec.
• How should other primitive constant types be treated? (eg, true, false)

Checklist

• Unit tests updated
• README updated
• examples/ directory updated (only applicable for openapi-typescript)

[changeset-bot]

🦋 Changeset detected

Latest commit: 4901efd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openapi-typescript	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mitchell-merry]

Where in the OpenAPI spec is const described? I couldn't find it in the 3.1 spec.

It's in the JSON schema spec: https://json-schema.org/understanding-json-schema/reference/generic.html#constant-values

How should other primitive constant types be treated? (eg, true, false)

I'm pretty sure they should be treated as the boolean values rather than the string "true"/"false". That's how the yaml spec works I believe. https://yaml.org/type/bool.html.

Edit: Actually, I think whatever parses the yaml/json file will (or should) determine this for us, right?

[drwpow]

This looks great to me! I can’t recall the reason why that particular code block in transform/schema-object.ts is so anti-idiomatic. So the fact that there’s no change to tests/output generation, and this PR cleans up that bit of code is probably a good sign overall 🙂