configs: allow full type constraints for variables #17538
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(This applies to the new configuration loader, which is not yet in use.)
Previously we just ported over the simple "string", "list", and "map" type hint keywords from the old loader, which exist primarily as hints to the CLI for whether to treat
-var=...
arguments and environment variables as literal strings or as HCL expressions.However, we've been requested before (e.g. #6254) to allow more specific constraints here because it's generally better UX for a type error to be detected within an expression in a calling
module
block rather than at some point deep inside a third-party module.To allow for more specific constraints, here we use the type constraint expression syntax defined as an extension within HCL, which uses the variable and function call syntaxes to represent types rather than values, like this:
string
number
bool
list(string)
list(any)
list(map(string))
object({id=string,name=string})
In native HCL syntax this looks like:
In JSON, this looks like:
The selection of literal processing or HCL parsing of CLI-set values is now explicit in the model and separate from the type, though it's still derived from the type constraint and thus not directly controllable in configuration.
Since this syntax is more complex than the keywords that replaced it, for now the simpler keywords are still supported and
list
andmap
are interpreted aslist(any)
andmap(any)
respectively, mimicking how they were interpreted by Terraform 0.11 and earlier. For the time being our documentation should continue to recommend these shorthand versions until we gain more experience with the more-specific type constraints; most users will just make use of the additional primitive type constraints this enables:bool
andnumber
.As a result of these more-complete type constraints, we can now type-check the default value at config load time, which has the nice side-effect of allowing us to produce a tailored error message if an override file produces an invalid situation; previously the result was rather confusing because the error message referred to the original definition of the variable and not the overridden parts.
This doesn't yet go so far as to enable user-specified validation expressions as requested in #2847, but it also doesn't close the door to such things. Something for this other use-case will probably be added at a later date. For now we will focus just on type-checking.