Linting shared modules repo

[msl0]

Hello!
I work on the development and maintenance of a repository with shared modules. I noticed that depending on whether we work with the root module or other modules, the way of using tflint may be different.

Note that there is a difference between calling a child module in an inspection and inspecting a child module as the root module.

This is structure of my repo:

shared-modules
├── .tflint.hcl
├── module1
│   ├── main.tf
│   ├── outputs.tf
│   └── variables.tf
├── module2
│   ├── main.tf
│   ├── outputs.tf
│   └── variables.tf
└── test
    ├── go.mod
    ├── go.sum
    ├── module1_test.go
    └── module2_test.go

.tflint.hcl:

config {
    disabled_by_default = false
}
plugin "terraform" {
    enabled = true
    version = "0.6.0"
    preset = "all"
    source  = "github.com/terraform-linters/tflint-ruleset-terraform"
}

plugin "azurerm" {
    enabled = true
    version = "0.25.1"
    source  = "github.com/terraform-linters/tflint-ruleset-azurerm"
}

I want to use the default rules and azurerm rules. I would like to confirm that what I need to do to make everything work is create .tflint.hcl in root path, then I can just use

tflint --init
tflint --recursive --config "$(pwd)/.tflint.hcl"

or (for single module):

tflint --init
tflint --chdir module1 --config "$(pwd)/.tflint.hcl"

I'm just looking for confirmation as I'm a bit confused by the different behaviors depending on whether it's a root module or a non-root module. I haven't found a complete example of how to use tflint with shared modules before

[wata727]

Note that the root module/child module relationship in terraform plan/apply may be different than the relationship in TFLint inspection. Terraform can hardly terraform plan/apply a shared module as a root module, but TFLint can inspect it as a root module. This allows you to check for issues specific to shared modules, such as the use of deprecated syntax.

On the other hand, issues caused by input variables cannot be found when inspected as the root module. In this case, similar to Terraform, you can find out by inspecting the actual root module that is called as a child module with --call-module-type=all/local.

Our recommendation is to inspect it both as a root module and (if possible) as a child module. This can generally be achieved with tflint --recursive --call-module-type=all/local, so you are already on the best practices.