Migrate to hashicorp namespace

[remyleone]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I need to be reassured that this project will be maintained even if bfald stops maintaining it. Could hashicorp publicly endorse this project? It could also help maintainers to have linters that would encourage them to migrate to the terraform framework. It could even provide some snippets of code to help them get started with this migration.

New or Affected Checks(s)

• AT###

Flagged Provider Code

// flagged code

Passing Provider Code

// passing code

References

• Links if you have any!

[mattdot]

Agree. This repo seems dead. It's incompatible with current versions of golang, hasn't been updated in a long time, and has proposed PRs from 2021. @bflad is this still a real tool that we should be using?

[bflad]

Hi @remyleone and @mattdot 👋 Thank you for raising this.

The main reason for this repository not seeing much action is because this static analysis tooling was designed mainly for the coding quirks associated with terraform-plugin-sdk that would cause developers issues. It was mainly focused on contribution and quality issues I noticed when I was a maintainer of the Terraform AWS Provider, but they felt generally useful to the larger provider development community at the time. Since then, I switched teams to the development experience team which maintained the SDKs, testing framework, and documentation tooling.

In that time period, my team at HashiCorp has released terraform-plugin-framework, a newer provider development SDK with benefits over its predecessor. While there has not been an official deprecation notice about terraform-plugin-sdk, its effectively in maintenance mode. Provider developers are generally encouraged to migrate their provider code from the prior SDK to the newer SDK. As it relates to this tooling, there were quite a few design decisions of the newer SDK that intentionally were to prevent the need for additional static analysis tooling, such as preferring compilation errors and unit testable concepts instead where possible.

So where does that leave this tooling? The majority of the non-testing rules are not as applicable since the prior SDK is not receiving so many features. For this tooling then, I wouldn't expect much, if any further changes for terraform-plugin-sdk based provider code checking. If there are terraform-plugin-framework related checks that should be created, I would assume folks would raise feature requests for those and that this tooling would fully switch to only terraform-plugin-framework code checks instead of supporting both SDKs. The testing rules, however, still continue to be relevant. For those, they should probably be migrated to the split-off and enhanced terraform-plugin-testing Go module. I think we would want to see what the community uses (or not) in that area before making any decisions though.

For now, I'm going to try spending some time to get this tooling in a better spot against the newer Go static analysis APIs without compatibility promises (e.g. #298) so it can still run on newer versions of Go for folks who are using it.

[remyleone]

Migrating to the new terraform-plugin-framework implies large refactoring and ongoing tasks such as maintaining several schemas for both resources and data ressources. This migration might not happen quickly (or at all) for some provider. In the meantime, it would still help to have the ownership transferred to hashicorp to ensure proper visibility.