Question about the caveats for calling modules

[ricardo-kh]

Hi,

First of all; thanks for the excellent work on tflint!

I have some questions about Calling modules - Caveats.

Basically I would like to better understand what those caveats mean.
To me they describe 'what' but not 'why'.

These are my questions, per caveat:

• Issues must be associated with a variable that was passed to the module. If an issue within a child module is detected in an expression that does not reference a variable (var), it will be discarded.

  • My question: why is it important that the expression needs to contain a variable that was passed to the module?

• Rules that evaluate syntax rather than content should ignore child modules.

  • My question: why should a rule do that? Is it because the syntax should be checked in the source repository of the module itself? And not from the configuration that uses the module, because it is not affected by (and has no control over) the syntax in a module anyway?

• If you want to evaluate all TFLint rules on non-root modules, inspect directly against the module directories. Note that there is a difference between calling a child module in an inspection and inspecting a child module as the root module.

  • My question: this is not about the 'why' but understanding that difference. Is the difference in behaviour described by the two other caveats?

Regards,

Ricardo

P.S. I did browse the code and I think I found where this logic resides (runner.go) but could not answer my own questions.

[wata727]

why is it important that the expression needs to contain a variable that was passed to the module?

This is because the feature was designed to find issues caused by module arguments. If an issue is reported that is not related to variables (module arguments), you will have to fix modules that are not under your control in order to fix all the issues.
Also, if you are inspecting a local module as the root module using --recursive, the same issues will be reported multiple times.

why should a rule do that? Is it because the syntax should be checked in the source repository of the module itself? And not from the configuration that uses the module, because it is not affected by (and has no control over) the syntax in a module anyway?

It's for the same reasons explained above. It wouldn't be a problem if the rules didn't ignore child modules, but it would be slower.

this is not about the 'why' but understanding that difference. Is the difference in behaviour described by the two other caveats?

Yes. Inspecting a child module as the root module will find any issues it has, such as syntax issues. Calling the child module will find any issues caused by input values in another module.

[ricardo-kh]

Thanks for the explanation.