CloudFormation parameters in templates, can either be String or
Number. It's common convention to support "booleans" as well by using
String with AllowedValues: [True, False]. CloudFormation parameters
when ultimately passed as part of a deploy must be strings. This
causes some edge cases, such as a stringified Number being passed at
deploy-time as "3.0", instead of "3" and then failing.
For this reason, we had some special handling for values that parsed
from the actual spec yaml as a number. Even with this present, we still
captured the value as a Text internally (with special ".0"-handling
pre-applied).
This causes user-facing confusion and complexity, since generation would
still always be at Text, even if the user had entered a numeric
literal in their spec yaml.
This commit changes that to retain the original type used in the
user-provided yaml, and only "cast" things to Text when necessary
(e.g. when need as a true Amazonka Parameter). This meant splitting
the newtype into an actual data type with cases for strings and
numbers. To this it adds a boolean case, encoding the "True|False"
convention described above.
Ultimately, this results in user-facing interfaces always using actual
string, number, or boolean types, and the necessary string casting
pushed further to the edges.
This changes the interface of Generate to deal in ParametersYaml
values instead of (Amazonka) Parameters, so this will need a major
version bump.
CloudFormation parameters in templates, can either be
StringorNumber. It's common convention to support "booleans" as well by usingStringwithAllowedValues: [True, False]. CloudFormation parameters when ultimately passed as part of a deploy must be strings. This causes some edge cases, such as a stringifiedNumberbeing passed at deploy-time as"3.0", instead of"3"and then failing.For this reason, we had some special handling for values that parsed from the actual spec yaml as a number. Even with this present, we still captured the value as a
Textinternally (with special".0"-handling pre-applied).This causes user-facing confusion and complexity, since generation would still always be at
Text, even if the user had entered a numeric literal in their spec yaml.This commit changes that to retain the original type used in the user-provided yaml, and only "cast" things to
Textwhen necessary (e.g. when need as a true AmazonkaParameter). This meant splitting thenewtypeinto an actualdatatype with cases for strings and numbers. To this it adds a boolean case, encoding the"True|False"convention described above.Ultimately, this results in user-facing interfaces always using actual string, number, or boolean types, and the necessary string casting pushed further to the edges.
This changes the interface of
Generateto deal inParametersYamlvalues instead of (Amazonka)Parameters, so this will need a major version bump.