I recently added a rule to TFLint to ensure that types are required for variables: https://github.com/terraform-linters/tflint/pull/721
Is there an easy way to determine if a type is missing or if it is declared as “any”? I am new to the Terraform code base and starting to learn more about the typing system, but from my understanding the absence of a type will be represented as a DynamicPseudoType
This is the code associated with the rule: https://github.com/terraform-linters/tflint/blob/master/rules/terraformrules/terraform_typed_variables.go#L45
Hi @mveitas,
I’m not very familiar with tflint so I can’t really answer this question with specifics, but I will say that from Terraform’s own perspective an omitted type argument and type = any are totally equivalent, and so Terraform doesn’t have any need to differentiate them.
I find the code you linked to a little confusing because on the surface it looks like it’s iterating over a []string value but then accessing a .Type attribute on each value. If you can say a little more about your understanding of how tflint works and what you’re trying to achieve here I might be able to offer some more specific answers.
from Terraform’s own perspective an omitted type argument and type = any are totally equivalent
I figured this was the case and 100% makes sense and what I am trying to do might not be possible.
TFLint is a linting tool for Terraform. In this case I am trying to automate as much of the code review process and force engineers to follow our company’s module best practices (one of which is to define a type for all variables).
TFLint will read configuration for a given module and iterate over all of the Variable objects that are found in that module. The TFConfig is just a reference to the Terraform Config object that contains Modules.Variables
Hi @mveitas,
Unfortunately what tflint is doing right now is totally unsupported: hashicorp/terraform is an executable program, not a library. While some of the packages are (for historical reasons) technically importable, please note that the versioning scheme of the repository relates to compatibility with Terraform as used through the CLI interface, and not to the internal Go package APIs. Your codebase is very likely to be broken by future changes to Terraform.
With all of that said, I think the above is also in a way the answer to your question: linters tend to differentiate things that a main language parser does not, and in order to do that they need to work at a lower level of abstraction than the main language implementation. In your case, I think that would be using the HCL library directly, and decoding the HCL data structure in whatever way gets you the details you need to implement the linter rules you want to implement.
For the specific problem you’re talking about for example, you could use the HCL API to decode the contents of the variable block itself (rather than Terraform’s higher-level representation of it) and then check whether there is an element called type in the map of attributes in that body. By dropping down one level of abstraction you can distinguish presence vs. absence in a way that Terraform’s application-level models do not.
Thanks or the info and something I will bring this feedback to the TFLint project.
OOC, is a linting tool something that Hashicorp might consider supporting in the future and making part of the Terraform tool chain?