defaults for terraform_remote_state data source outputs

[chernetskyi]

Background

terraform_remote_state data source has a defaults attribute that sets default values for outputs, in case the state file is empty or lacks a required output.

Suggestion

Since there are rules for unused locals, variables, and data sources, there just as well might be a rule that indicates values in defaults without the respective output.

In addition, it'd be great to have an opt-in rule that requires a default for every output in use.

Example

Linting

data "terraform_remote_state" "example" {
  backend = "local"

  config = {
    path = "../example"
  }

  defaults = {
    foo = "somevalue"
  }
}

locals {
  bar = data.terraform_remote_state.example.outputs.bar
}

should result in

Warning: default value for output "foo" is declared but the value is not used

Warning: remote state "example" does not contain a default value for output "bar"

[bendrucker]

here just as well might be a rule that indicates values in defaults without the respective output.

It's an interesting thought but not equivalent and unlikely to be something we'd pursue. Here's why.

The things we can detect as unused like resources and even locals are part of blocks, which are part of the almost entirely static structure of the document/module.

Terraform/HCL also has expressions, which represent evaluation, often only fully possible at runtime. aws_instance.foo.arn is an example of a dynamic expression, "foo" is a static expression. TFLint can evaluate the later.

Importantly, locals is not an expression, it is a block declaration. The keys and values in the contained map are each expressions, but the outer structure is not. This is not valid:

jsonencode(locals)

Detecting unused config depends on these structural keywords like locals, resource, and data and the fact that they cannot be used as values in a (potentially dynamic) expression. Expressions must reference them in a way that is also inherently statically analyzable. A declaration is always used or unused, never ambiguous.

The defaults and outputs attributes, in contrast, are expressions (map[any]). It is not always possible to detect dead code in expressions using static analysis.

Take this example:

output "remote_state" {
  value = data.terraform_remote_state.foo.outputs
}

Or this:

output "foo" {
  value = data.terraform_remote_state.foo.outputs[data.terraform_remote_state.foo.outputs.foo_key]
}

Even for the cases that are theoretically statically resolvable you'll also need a lower level HCL strategy. With keywords you can easily get the references from an expression, at a Terraform language level:

https://github.com/terraform-linters/tflint/blob/b7bc5fee2e01623c52023b18c0fa961a38f25069/terraform/lang/references.go#L44

But with expressions you'd have to visit every expression that references the remote state object and go through the traversals hcl.Traversal yourself.

If you want to take a stab at a PR I'd be happy to help via review but given the high complexity and low payoff this won't be a priority otherwise.