Added rule to check "this" name for single resource of a type

[janritter]

This rule checks for point 2 from the Terraform Best Practices for naming

Resource name should be named this if there is no more descriptive and general name available, or if resource module creates single resource of this type (eg, there is single resource of type aws_nat_gateway and multiple resources of typeaws_route_table, so aws_nat_gateway should be named this and aws_route_table should have more descriptive names - like private, public, database).

[bendrucker]

Hmm, I think this ruleset (moving to its own plugin soon) is best limited to conventions mentioned in the official Terraform docs. I've seen this used as a resource name in the wild. It's a perfectly reasonable convention, but it's closer to a personal preference than a well-accepted best practice.

[janritter]

I understand your point. One of the reasons for adding this rule into the tflint core rules was to easily be able to use them in pre-commit.
Adding a pre-commit config for a whole repo (which enables the individual rules) is easier than adding a tflint config per folder in the repo (to enable the plugin), this might be forgotten at some point.
Is there a plan to be able to enable plugins via command line options as well in the future?

This whole question is not directly related to the rule, should I create a separate issue for it?

Example pre-commit config:

fail_fast: true
repos:
  - repo: git://github.com/antonbabenko/pre-commit-terraform
    rev: v1.45.0
    hooks:
      - id: terraform_tflint
        args:
          - '--args=--enable-rule=terraform_unused_declarations'
          - '--args=--enable-rule=terraform_naming_convention'

[bendrucker]

Is there a plan to be able to enable plugins via command line options as well in the future?

No plan, but it's a reasonable idea. But it also sounds like your use case would be solved if TFLint walked up to the root looking for config files and merged everything it found.

Mentioned here:

#841 (comment)

As opposed to flags for enabling/disabling rules/plugins, this would provide total config control and allow "overrides" for specific sub-directories.