What Is New in Terraform 1.3
Terraform 1.3 introduces optional object type attributes and expands the capabilities of the `moved` configuration block, alongside several enhancements to the Terraform Cloud integration and core functions.
| Category | Key Changes |
|---|---|
| Language & Core | Optional object attributes, `moved` block support for modules |
| Cloud Integration | New `cloud` block, structured run output |
| CLI & UX | Improved error messages, `terraform show` JSON output |
| Provider Dev | Provider-defined functions, plan-time validation |
How does optional object attributes improve module design?
Optional object attributes let you define module variables where certain nested attributes can be omitted. This makes your modules far more flexible when dealing with complex, nested data structures.
You declare them using the optional modifier within an object type constraint. In practice, this
means you no longer need to specify every single nested attribute if it doesn't have a sensible default,
simplifying your variable declarations significantly.
variable "example" {
type = object({
required_attr = string
optional_attr = optional(string)
})
}What can the moved block do for modules now?
The moved block now supports refactoring within modules, not just for resources. This is a
game-changer for cleaning up complex, mature modules without breaking existing user configurations.
You can use it to rename a module, split one module into several, or change the source of a module. Terraform will automatically update the state to reflect the change, which prevents a lot of manual state surgery during module upgrades.
moved {
from = module.old_name
to = module.new_name
}How is the Terraform Cloud experience enhanced?
This release formalizes the cloud block configuration as a stable feature, moving it out of the
experimental phase defined in version 1.2. It's the recommended way to configure Terraform Cloud and Terraform
Enterprise workspaces.
Additionally, the CLI now emits structured run output when executed in a Terraform Cloud environment. This provides a cleaner, more machine-readable summary of the plan and apply phases, which is great for automation and parsing logs.
What CLI improvements should I know about?
The terraform show command can now generate JSON output for plan files (-json flag).
This unlocks powerful automation possibilities, allowing other tools to easily parse and react to the contents
of a saved plan.
Error messages, particularly for the moved block and certain configuration issues, have been refined
to be more precise and actionable. You'll spend less time deciphering what went wrong.
FAQ
Is the `cloud` block backwards compatible with the `backend` block?
Yes, the `cloud` block
configuration is functionally equivalent to the `cloud` backend that was introduced as experimental in v1.2.
Your existing `backend "cloud"` configuration will continue to work, but HashiCorp recommends transitioning to
the new block for clarity.
Can I use optional attributes with collections like maps and lists?
No, the `optional`
modifier is specifically for attributes within an object type constraint. It does not apply to individual
elements within collection types like maps or lists.
Does the `moved` block for modules work with a `terraform state rm` command?
No, the `moved`
block is a configuration-based operation. You should not manually remove the old module from state with
`terraform
state rm` before using a `moved` block, as the block itself handles the state update.
What happens if I don't provide a value for an optional attribute?
If a value for an optional
attribute is not provided, Terraform will treat it as if it were set to `null`. Your module code should be
written to handle this potential null value.
Are there any new functions added in this release?
No, Terraform 1.3 does not introduce any
new built-in functions. The major language enhancements are focused on type constraints (optional attributes)
and refactoring (`moved` blocks).