Fix OpenAPI YAML converts strings to boolean

[wanlwanl]

Problem: yaml 1.1 treats some string as other types of value. Check out: https://perlpunk.github.io/yaml-test-schema/schemas.html
Fix: #5377
Solution: make serialization compatible with YAML 1.1
Todo: test other types (in next PR).

[azure-sdk]

All changed packages have been documented.

• ✅ @typespec/openapi3

Show changes

@typespec/openapi3 - fix ✏️

Fix: OpenAPI YAML converts strings to boolean

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	📚 Next docs	🛝 VSCode Extension

[timotheeguerin]

I don’t think we should do that, there was already a discussion about this. Openapi recommend using yaml 1.2 we shouldn’t try to use 1.1 at least by default.

In order to preserve the ability to round-trip between YAML and JSON formats, YAML version 1.2 is RECOMMENDED along with some additional constraints

[wanlwanl]

I don’t think we should do that, there was already a discussion about this. Openapi recommend using yaml 1.2 we shouldn’t try to use 1.1 at least by default.

In order to preserve the ability to round-trip between YAML and JSON formats, YAML version 1.2 is RECOMMENDED along with some additional constrain
@timotheeguerin
How about add a new OAS3 emitter option like this:

    "yaml-version": {
      type: "string",
      enum: ["1.1", "1.2"],
      nullable: true,
      default: "1.2",
      description:
        "Specifies the YAML version to use when processing or generating YAML files. The default value is 1.2. Supported values are:\n- 1.1: For compatibility with older YAML specifications.\n1.2: For compliance with the latest YAML standard.",
    },

[chrisradek]

I see 2 options using the yaml library:

1. Set compat: "yaml-1.1" as one of the stringify options. This will attempt to emit yaml that is compatible with yaml 1.2 and 1.1 (and does what we want for these true/false string values).
2. Set the toStringDefaults.defaultStringType to Scalar.QUOTE_SINGLE or Scalar.QUOTE_DOUBLE. This will cause all strings to be wrapped in quotes though, including key names.

I think option 1 provides a nicer looking output, but I don't know what edge cases we might run into with the compatibility mode set - I don't think we're doing anything too fancy though where this should be a problem.