Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

terraform_typed_variables - unable to distinguish between missing type and "any" type #741

Closed
mveitas opened this issue May 7, 2020 · 3 comments · Fixed by #745
Closed
Labels

Comments

@mveitas
Copy link
Contributor

mveitas commented May 7, 2020

The following variable declarations will fail for the rule terraform_typed_variables

variable "lifecycle_rules" {
   description = "S3 bucket lifecycle rules"
   type        = any
}

This appears to be an issue with the underlying typing system used by Terraform and not being able to distinguish between a missing and any type declaration

Version

TFLint v0.15.5

@mveitas
Copy link
Contributor Author

mveitas commented May 8, 2020

Link to a discussion on the Hashicorp forum about this issue: https://discuss.hashicorp.com/t/is-there-a-way-to-distinguish-any-type-from-no-type/8513

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.

@wata727
Copy link
Member

wata727 commented May 8, 2020

Thanks, @mveitas.

As he says, In this case, we should parse the HCL file directly instead of accessing the Terraform's configuration object.

Btw, TFLint uses Terraform's internal APIs for a lot of processing to make some implementations easier, but I understand it's not a good way. I hope a static analysis will be provided as a core feature of Terraform in the future, but until then I think it will be necessary to provide this tool as a hack. This is one of the reasons why TFLint is not yet "stable".

@wata727 wata727 added the bug label May 8, 2020
@mveitas
Copy link
Contributor Author

mveitas commented May 8, 2020

I'll update the docs for the rule with this exception for the time being

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

2 participants