-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to hashicorp namespace #263
Comments
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? |
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. |
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. |
Community Note
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)
Flagged Provider Code
// flagged code
Passing Provider Code
// passing code
References
The text was updated successfully, but these errors were encountered: