Commits on Mar 8, 2018

1. configs: allow full type constraints for variables …

   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 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:
   
       variable "foo" {
         type = map(string)
       }
   
   In JSON, this looks like:
   
       {
         "variable": {
           "foo": {
             "type": "map(string)"
           }
         }
       }
   
   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" and "map" are
   interpreted as list(any) and map(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 should just make use of the additional primitive type constraints
   this enables: bool and number.
   
   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.

   

   apparentlymart committed Mar 8, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for 3c6ad62
   • Browse repository at this point

   Copy the full SHA

   3c6ad62 View commit details

   Browse the repository at this point in the history