Sending all emittedIssues generated using --module flag back to calling file

[Prasheel-IITI]

I am working on a plugin tflint. I am scanning terraform files using --module flag to get linting upon passed variables if present. However some of the variables if not present in module can be linted at module name.
I am facing the issue that --module flag scans the inner module but only sends linting instructions for variables that have been passed through the module. Linting instructions for all other variables are getting generated but not getting through to the module itself.

module "Custom" {
     source = ".//sub-module"
     type = "gp2"
}

Here the variable type gets linted if some issue has been passed over. If there is some other variable within ./sub-module that has not been defined in "Custom" module, raised issue for it gets ignored. I want to catch that issue. Is there some existing way to do it ?

[wata727]

In such cases, I think you should scan the .//sub-module module directly.

The main purpose of module inspection (scanning with --module flag) is to detect issues caused by module arguments. In other words, this is module "call" inspection.

Issues that do not depend on the module arguments reside in the child module itself, so the child module itself should be scanned.

[Prasheel-IITI]

I am also using remote modules as child. So, I won't be able to lint at the child module always. Is there a way to get all issues for remote modules ?

[bendrucker]

Non-root modules are categorized into child modules (local) or published modules (remote).

https://developer.hashicorp.com/terraform/language/modules

By design, TFLint cannot be readily run on published modules. TFLint is not an enforcement mechanism. If you need to enforce that some attribute is set on every instance of a giving resource type, for example, TFLint is not suitable for that task. See terraform-linters/tflint-ruleset-aws#53 (comment) for a full explanation.

TFLint's intended purpose is as a development aid, to surface issues early through static analysis, so that the module author can fix them. The content of a called module is inherently out-of-scope, except with respect to the arguments passed in by the caller.