tflint doesn't work on resources using foreach

[vaibhavkhurana2018]

// Write code here
resource "aws_instance" "foo" {
  for_each     = toset(["t2.medium", "t1.xlarge"])
  ami           = "ami-0ff8a91507f77f867"
  instance_type = each.instance_type # invalid type!
}

provider aws {
}

Version

$ tflint -v
TFLint version 0.29.1
+ ruleset.aws (0.4.1-bundled)
$ terraform -v
Terraform v1.0.0 (Tested with 0.15/0.14 etc as well.)
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v3.46.0

Tflint works perfectly fine without the for_each construct.

Since most of the modules use for_each for us, it is a blocker for us to use tflint.

[bendrucker]

While TFLint can evaluate resources that use for_each, it does not currently attempt to statically evaluate the for_each expression and evaluate the resource block multiple times with each set.

This is expected behavior for the moment.

[vaibhavkhurana2018]

@bendrucker Thanks for the revert. Can you suggest any workaround for using TFLint with resources using for_each.

Since looping constructs are one of the biggest advantages by newer versions of terraform, are we thinking of implementing this in the roadmap, else all those resources will be silently ignored.

I can see that there were discussions around getting TFLint over plan files, if there are plans around that then that can also potentially solve this issue. But can see that the issue is silent for sometime now, https://github.com/terraform-linters/tflint/issues/328

[bendrucker]

Updated #328 to mention that we are not doing plan inspection and suggest some alternatives. TFLint is a static (code) analysis tool and there will always be limitations on what suggestions it can offer. The example you shared can be statically evaluated and we could reproduce Terraform's for_each handling. But references to data sources and resources will always be ignored, since those depend on state.

I've also opened #1139 to track each evaluation support with a concise explanation of what's going on. We can consider local and each support once Terraform 1.0 support has landed. That will involve major changes to the configuration parsing and expression evaluation components of TFLint. We can evaluate the feasibility of "advanced" expression parsing (i.e. statically evaluable references to local and each) after that's shipped.

In the near term, if plan analysis is appealing to you, there's other tools out there mentioned in https://github.com/terraform-linters/tflint/issues/328#issuecomment-866093585 that can do that today.

[vaibhavkhurana2018]

But references to data sources and resources will always be ignored, since those depend on state.

Completely agree on the usage of data sources and the case of interfacing with the state file.

The example you shared can be statically evaluated and we could reproduce Terraform's for_each handling.

What i am more interested on is the static analysis of the code based on a similar setup, where we have a static code post the looping construct, and using TFLint on top of it. Like in this case the static code to be evaluated is similar to:

resource "aws_instance" "foo" {
  ami           = "ami-0ff8a91507f77f867"
  instance_type = "t2.medium"
}

resource "aws_instance" "foo1" {
  ami           = "ami-0ff8a91507f77f867"
  instance_type = "t1.medium" # invalid type!
}

Apologies if i am asking a noob question, but if there is some way to achieve this via TFLint will be more than happy. Not looking out for anything involving things with reference to data sources or state files.

there's other tools out there mentioned in #328 (comment) that can do that today.

Correct, have been working with OPA for other such use cases that involves dealing with plans/state files, but what interests me on TFLint is the subset of 700+ rules, that the stack offers, so if there is an potential to utilise the good efforts done, and not write all those rules via OPA myself, will be more than happy to have that use case. Again just for the static code generated post the looping construct.

[bendrucker]

There's no workaround, this is just complex evaluation that TFLint doesn't do. The difficulty of implementation and therefore somewhat long time horizon for when you might see this is described in #1139.