How to lint only in a specific directory?

[nwalters512]

I half-asked this question in #1304 before it was locked. As requested, I'll describe my scenario and what I'd like to be able to do.

I have a monorepo. It contains many things, but the relevant part for tflint is that it contains various bits of Terraform configuration exclusively in a terraform directory in the root of the repository. The actual "workspaces" are at various locations within that directory, e.g. terraform/honeycomb/main.tf and terraform/aws/prod/main.tf. I have a .tflint.hcl file in the root of the repository as well.

Currently, I can run tflint --recursive, which works well enough. However, as far as I can tell, it's recursing into every directory in the repository, even those that will never contain .tf files (they're all nested exclusively under the terraform directory). This makes it run slower than it otherwise could.

I can see two ways to solve this:

• Allow tflint to receive a set of directories to run on like Prettier, ESLint, etc: tflint --recursive ./terraform
• Allow tflint to be configured with a set of directories to ignore so that I could ensure it doesn't waste time recursing into irrelevant directories (e.g. node_modules).

It was suggested in #1304 that I could run tflint --chdir ./terraform --recursive, which is close to my first solution above. This is currently disallowed, and it fails with the following error message:

Failed to find workspaces; cannot use --recursive and --chdir at the same time

If this were to be supported, I'm not sure if it'd meet my needs. Specifically, based on my reading of the current documentation, tflint wouldn't discover the .tflint.hcl file at the root of my repository with --chdir. It's possible that #1929 would help here, though I guess it'd be an implementation choice as to how --chdir would interact with a new config system.

[wata727]

Thank you for your feedback.
Just a question, does cd terraform; tflint --recursive not meet your needs?

[bendrucker]

So yes, the straightforward answer is to put a little wrapper script in your repo or environment to call with the absolute path and that'll override the per-module discovery. There's a relationship to the default .tflint.hcl config path too. I'll grab a link to that issue.

Given that it might be more appropriate to resolve --config in the working directory when explicitly set. That won't spare you the need to set it but it would at least eliminate the need to supply an absolute path.

[nwalters512]

I understand that it's not a 1:1 comparison, I'm just providing the frame of reference I'm coming from. The simplicity of my setup (I don't want/need to customize things per-module; I want the same plugins and rules applying to everything) might make this seems like more of a rough edge than if I wanted all that customization, in which case I'd just stick a .tflint.hcl file in every module and call it a day.

Even given that we're dealing with modules and not individual files, my mental model was that if I stick a .tflint.hcl in some parent directory (maybe inside terraform, I don't want to get hung up on the fact that the config file is currently in the root of the repo), that config file would apply to all modules nested somewhere under that directory.

I'll reiterate that it seems like #1929 would meet my needs here, in the sense that if cascading config is implemented, a "root" .tflint.hcl would be discovered and applied to all modules. I can add a wrapper script for now; I guess this is what Makefiles are for!

[bendrucker]

Memory was slightly off, the related change in question is this:

#1940

It used to be that --config .tflint.hcl would work regardless of the presence of a config file, since that was the default value for the flag and was handled equivalently whether unset or explicitly set to the default.

So if you expected your configuration to be resolved in the working directory with --recursive, you'd get a silent noop instead of an error.

Still, changing where --config is resolved would break all existing users who do have per-module configuration files. That's where the absolute path treatment comes from. It's an unambiguous and non-breaking way to bypass that.

[bendrucker]

👍🏻, #1929 is the issue to track given your setup.

I am partial to cascading personally. It solves the simple case of a root config file but also allows for upward merging of configuration. If you can organize your monorepo accordingly it always seems like the "best" way to do monorepos. The flat config file is always the most flexible but leads to sprawl and an inability to readily execute in a single module from its own working directory.

[wata727]

Thank you for your inputs. It may seem strange that the --config option does not always resolve from the original directory, but this is inspired by Terraform's --chdir design philosophy.

The --chdir resolves all paths from the changed directory. The --recursive works like this because it works with --chdir. However, I agree that this may not be convenient from a user's perspective.

At this point, I'm also in favor of starting with configuration cascading.

[bendrucker]

Why is the config file at the root of your repository if all Terraform content is in a specific directory? If you use a terraform dir by convention it seems like you could just include your config there.

[nwalters512]

By convention we have all our tooling config files in the root of the repo. I'm open to making an exception for tflint, but based on what I discussed in the other thread here, that wouldn't dramatically change how I'm invoking tflint. As far as I can tell, moving the config around would only net me this:

-(cd terraform && tflint --recursive --config $(realpath ../.tflint.hcl))
+(cd terraform && tflint --recursive --config $(realpath .tflint.hcl))