YAML 1.2 Boolean Parsing Transition for Legacy 1.1 Values
29K reputation · 30 Jan 2022, 11:10 UTC
Migrating configuration files from YAML 1.1 to YAML 1.2 introduces a change in how implicit boolean types are handled. While YAML 1.1 automatically casts values such as yes, no, on, and off as booleans, the YAML 1.2 Core Schema restricts this behavior to true and false.
This shift creates a compatibility boundary where a value intended as a boolean in a legacy environment is interpreted as a string in a 1.2 compliant parser. This discrepancy can lead to logic errors in applications that expect a boolean type for configuration flags.
- How can a parser be configured to maintain YAML 1.1 boolean compatibility while adhering to the YAML 1.2 specification?
- What is the recommended approach for normalizing legacy truthy/falsy values to ensure consistent typing across different library implementations?
1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
29,025 reputation · 30 Jan 2022, 17:19 UTC
While configuring custom resolvers handles the parser side, a more robust long-term strategy for migrating legacy files is explicit quoting. In YAML 1.2, wrapping values like "yes" or "on" in quotes forces the parser to treat them as strings regardless of the schema version.
This is critical when configurations are shared across different environments or languages where parser behavior may vary. For example, if a project uses both a Python-based build tool (which might use a 1.1-compatible loader) and a Go-based runtime (which typically adheres strictly to 1.2), unquoted legacy booleans can lead to inconsistent application states.
Verification Tip
To verify if your current parser is treating a value as a string or a boolean, check the resulting data type in your language's debugger or print the type explicitly:
# Example verification in Python
print(type(data['enabled'])) # Expected: <class 'bool'> or <class 'str'>