Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider Migrating Some/All Validators into terraform-plugin-framework #186

Open
1 task done
bflad opened this issue Jan 8, 2024 · 0 comments
Open
1 task done
Labels
enhancement New feature or request

Comments

@bflad
Copy link
Contributor

bflad commented Jan 8, 2024

Terraform CLI and Framework Versions

Any Terraform CLI and terraform-plugin-framework version.

Use Cases or Problem Statement

We had separated out this Go module originally because we were not sure how the ecosystem would evolve with all the new framework validation concepts, since we really wanted developers to use custom types when possible, and wanted to leave the room for separate versioning of these declarative validators. Over a year after the framework v1.0.0 release now though, this validators Go module has been surprisingly stable. To prevent future developers from needing to discover and include this Go module as a separate dependency, the validators can be implemented directly in the terraform-plugin-framework Go module.

Proposal

The general process would be:

  • Introduce new validator packages and implementations in terraform-plugin-framework containing functionality from this Go module. Update all Go and website documentation to point to the now-native validator implementations. If this proposal is accepted, a feature request issue would be created in terraform-plugin-framework to discuss these details.
  • Add Deprecated: Go documentation to all exported functionality in this Go module and a big deprecation changelog
  • Cut a release
  • Archive the repository and celebrate this fun milestone 🎉

Caveats that can be discussed in this issue:

  • It is unclear whether all the existing validators should move over as-is because another option we do have in some of these cases is introducing very common use case validations into the framework base types themselves. e.g. basetypes.StringType{RegularExpression: ...}
  • Whether naming of some existing validators would be adjusted, as they would now more "permanent" due to compatibility concerns.
  • Whether the implementation details of some existing validators would be adjusted, as they would now be more permanent (potentially be testing those changes in this Go module first).

Additional Information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@bflad bflad added the enhancement New feature or request label Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant