Feature request: Terraform raw source includes

Terraform
1

Terraform variable blocks can now be quite rich in terms of specifying deeply nested types and runtime validations. Example:

variable "config" {
  description = "Instance configuration"
  type = object({
    block_volumes = map(object({
      delete_on_termination = bool
      volume_size = number
      volume_type = string
    }))
  })
}

In large, modular projects, it would be useful to be able to define these rich types and their validations in a single place, and then share these declaration blocks across many modules, e.g., when you want to pass config to another module. Current SO answers recommend symlinking files, which is not ideal.

If Terraform had a raw “include” style functionality like the C preprocessor, no language/parser/semantics would need to change, but rich type sharing across modules would become trivial without symlinking or a lot of copy/paste, allowing for safer, multi-module projects.

2

Hi @mayanklahiri!
It would be best to post this feature request to the GitHub repo where Terraform is maintained: Issues · hashicorp/terraform · GitHub
I would +1 your request for sure! :raised_hands:

3

Hi @mayanklahiri,

We don’t plan to ever support C-preprocessor-style includes that literally paste the raw content of one file into another, because that creates a significant hazard of the overall assembled source code not making any sense after assembling and does not offer any kind of hygiene to limit the scope of what is included so that it doesn’t have accidental global effects outside of its explicit goal.

Symlinking files is indeed an existing pattern that some people use, and is effectively functionally equivalent to a C-preprocessor-style include in that Terraform is just seeing a bunch of extra source code with no kind of encapsulation. All of the problems of that technique apply equally to a syntax-unaware (“unhygienic”) preprocessor.

Putting aside the specific proposal of a preprocessor or symlinks, I think the use-case you are describing is already covered by this existing issue:

You can see some previous discussion there about finding a compromise between using different design patterns that better suit today’s Terraform language vs. adding significant new complexity to the language to accommodate patterns that aren’t such a good fit for today’s Terraform.

Another concern we have that doesn’t seem to be represented in that issue yet is the idea of a module’s interface being self-contained. Today’s Terraform has the nice property that you can understand the input values and output values of a module completely with only that module’s source code, and so we’re nervous about adding new capabilities which would make it necessary to retrieve other modules to fully understand what a module expects and what it produces. This is a concern both for humans trying to learn how to use a module they’ve found and for existing tools that analyze Terraform modules to generate documentation for them, both of which can rely on the information being all together in one place today.

We can still discuss the use-cases further in that GitHub issue, though. Nothing is decided for that yet and so there’s still room for further design discussion, although nobody on the Terraform team at HashiCorp is currently focused on that particular request so I can’t promise any immediate action there.

Thanks!