terraform_module_version - feature request/suggestion

[TashunkoWitko]

The terraform_module_version rule offers the configuration option exact if an exact version should be pinned.
See: https://github.com/terraform-linters/tflint-ruleset-terraform/blob/main/docs/rules/terraform_module_version.md#configuration

We would like to enforce the usage of the pessimistic constraint operator operator across our organization.
https://developer.hashicorp.com/terraform/language/expressions/version-constraints#-3

Now i see two options to achieve this:

• Option 1: contribute to this repository and allow the configuration to demand pessimistic constraint operators
• Option 2: we define our own custom ruleset with one rule in it for the use of our org only

Do you see it as beneficial if the existing rule in this repository would be enhanced? If yes i could open a PR with my ideas. Appreciate any inputs/suggestions from your side. Thanks for your feedback!

[bendrucker]

Generally we try not to allow too much configuration into these rules around style preferences since that becomes a chore to maintain.

The exact option is at least oriented around a tooling pattern. Arguably not the best one, since users should be focusing on lockfiles as a means of version parity enforcement, as noted in the caveat.

Two thoughts on your proposal:

1. It seems like an organization style preference and not something we can tie back to any sort of documentable practice.
2. Pessimistic constraint seems particularly hazardous because it's an operator. Adding minor and major attributes would extend the existing exact attribute in describing the scope of a version range. Pessimistic allows you write ~> 1.1.0 and ~> 1.1 to express the idea of pinning to a minor or major version, respectively.

The opportunity for extended discussion and nitpicking here is typically why we've tried to minimize the amount of surface area by restricting to official Terraform docs guidance.

[TashunkoWitko]

Thank you for your point of view and i appreciate the quick response!
Maybe some more insights from our side why we do what we do in response to your thoughts:

1. Yes that is true, it is our organization style, but likely also used by other orgs.
   We use the tool based approach described in the docs for the exact version (see https://github.com/terraform-linters/tflint-ruleset-terraform/blob/main/docs/rules/terraform_module_version.md#exact-versions). Instead of renovate flooding us with patch and minor version updates, we would like to "let it slide" for patch/minor versions and only get pull requests for minor/major versions depending on the use case
2. I like that idea, i guess you could have an attribute pessimistic to demand a pessimistic versioning and two attributes to control the scope of the version range
3. or to reduce complexity to just introduce a pessimistic configuration option that checks for one or the other pessimistic versioning option. to avoid conflicts with the exact config option, that option could just take precedence if both are specified

Do you see a way this could be implemented as part of this repo or should i look to option 2 (our own ruleset)?

[bendrucker]

Do you see a way ... ?

Not yet, you should look to your own ruleset for the near term. The issue with style preferences is not that they're unreasonable but that they are many in number and often interact with each other. It is orders of magnitude easier to solve on behalf of a single organization and its relatively narrow set of preferences vs all users. I'm not eager to spend a bunch of time sorting through the various common usage patterns here.

Feel free to share a proposed API for this (i.e. config, not implementation). Ultimately it's something you're going to have to do anyway in an org-specific rule. It's helpful to include this in the original post as it shows you've seriously engaged with the configuration/abstraction problem.