Terraform 1.15 Closes Gap to OpenTofu on Dynamic Sources and Deprecation
HashiCorp has rolled out Terraform 1.15, a release that brings a suite of enhancements aimed at improving the flexibility, maintainability, and testing capabilities of infrastructure as code. This update is particularly noteworthy as it introduces features that have been highly anticipated by the community, some of which have already been available in the OpenTofu fork for a considerable period, effectively closing a functionality gap between the two platforms.
One of the most impactful additions in Terraform 1.15 is the introduction of dynamic module sources. Previously, module source and version attributes were restricted to string literals, forcing organizations to duplicate module blocks when different environments required varying registries or version pins. The new capability allows for the use of variables within these attributes, providing a more dynamic and less repetitive approach to module management. This flexibility extends to nested modules, provided their input variables are also declared with `const = true`, enabling resolution during the `terraform init` phase.
Another significant language change is the implementation of a formal deprecation mechanism for variables and output blocks. Module authors can now embed deprecation messages directly within their configurations. When a caller interacts with a deprecated variable or references a deprecated output, Terraform will issue a warning diagnostic during validation. This feature is designed to streamline the communication of interface changes, which previously relied on release notes alone, and facilitates a more controlled evolution of module interfaces. Daniel Schmidt, a core engineer at HashiCorp, elaborated on this, explaining that module authors can release new versions without deprecated variables after a grace period, ensuring a smooth transition for users.
Terraform 1.15 also addresses long-standing issues in the testing framework. A notable improvement is the ability to use functions within `mock_data` and `override_resource` blocks. This resolves a frequent complaint from developers who struggled to dynamically generate test data, especially for formats like GUIDs or resource IDs, which previously could not be created using functions like `uuid()` within mock blocks.
Further enhancements include a new `convert` function for inline type conversion, which tackles edge cases in HCL where Terraform's type inference might produce unexpected results. The release also introduces type constraints for output blocks, offering more robust validation and predictability. Additionally, Terraform 1.15 now provides native Windows ARM64 support, expanding its compatibility and reach across different operating environments.
The community's reception to Terraform 1.15 has been largely positive, with many engineers viewing it as a release focused on practical, long-requested fixes rather than flashy new features. Ashish Kasaudhan highlighted that this update addresses problems that platform teams have been vocal about for years, making it one of the most engineer-centric Terraform updates in recent memory. Davlet Dzhakishev pointed out a small but practically significant change: the `terraform validate` command now validates the backend block, checking for the existence of the backend type and required attributes. This prevents misconfigured backends from failing only at `terraform init` time, saving valuable CI pipeline minutes.
It's important to note the context of OpenTofu, the open-source fork of Terraform. OpenTofu had already shipped equivalent functionality for dynamic module sources, termed 'early variable and locals evaluation,' in its 1.8.0 release in August 2024. This feature, which allowed variables and locals in module sources, backend configuration, and state encryption settings, was the top-voted issue on the OpenTofu GitHub at the time. Similarly, OpenTofu 1.10 included a deprecation capability, although with differing implementation details. This indicates a convergence in addressing critical user needs across both Terraform and its fork, driven by strong community demand.
Read original source