Now generally available, HashiCorp Terraform 1.3 introduces optional object type attributes with defaults, and enhancements to moved blocks, improving extensibility and maintainability of Terraform modules.
We’re excited to announce the release of HashiCorp Terraform 1.3, now immediately available for download as well as for use in HashiCorp Terraform Cloud. Terraform is widely adopted as the standard for multi-cloud provisioning and automation for individuals and teams at any scale. This release introduces optional object type attributes with defaults, and expands the capabilities of moved
blocks. These changes improve the extensibility and maintainability of Terraform modules and help users to more easily refactor a Terraform code base as it grows.
Terraform variables support a feature known as type constraints. This argument allows module authors to validate the type of value supplied to input variables. In more complex scenarios, there may be a need to group multiple values into a single variable. A common solution in these scenarios is to use the object
type, which is a collection of named attributes that each have their own type.
To support this approach even further, the community proposed a feature that would allow marking an object’s named attributes as optional. This feature was added to Terraform 0.14 under experimental support and eventually became one of the most upvoted community GitHub issues.
As a result of that community support, Terraform 1.3 graduates the optional object type attribute feature from experimental status and adds the ability to set a default value. The benefit of this feature is to provide module authors a way to extend their modules to handle more complex use cases using the object
type without forcing module consumers to provide values for attributes that are not relevant to their work.
Below is an example of using the optional object type attribute with a default value when defining a variable as "ingress_rules"
:
You can apply the following values to this variable:
The resulting variable value will be:
The moved
block, introduced as part of Terraform 1.1, provided a programmatic method for refactoring resources within a Terraform configuration file. This update removed the dependency on using terraform state mv
, which was manual, error-prone, and would often lose the context of refactor operations to the command line history. There was one limitation with the initial release of the moved
block: they only supported refactoring moves if they were between modules within the same local path.
Terraform 1.3 improves moved
blocks by adding the ability to refactor resources to third-party and separately sourced modules. This includes modules sourced from the Terraform Registry, a private registry in Terraform Cloud, or any of the other options available through the source
argument.
Below is an example of using the moved
block to refactor a resource into a module sourced from Terraform Cloud’s private registry:
For more details, please see the full HashiCorp Terraform 1.3 changelog. This release wouldn't have been possible without all of the great community feedback we've received via GitHub issues, as well as continued feedback from our customers. Thank you!
HashiCorp’s Terraform provider for AWS now enables users to manage their S3 Express buckets.
A new view in the HashiCorp Terraform extension for Visual Studio Code shows your Terraform Cloud workspaces and runs, reducing context-switching.
A recap of HashiCorp infrastructure and security news and developments on AWS from the past year, from self-service provisioning to fighting secrets sprawl and more.