Consider Multiple Imports for Schema Functionality

[bflad]

It is possible for implementations to require multiple imports when defining validators (and likely other schema functionality). In this example, the implementation requires both the given import and the Go standard library regexp import, however there is no current methodology for defining the regexp import.

"validators": [
  {
    "custom": {
      "import": "github.com/hashicorp/terraform-plugin-framework-validators/stringvalidator",
      "schema_definition": "stringvalidator.RegexMatches(regexp.MustCompile(/* ... */), \"...\")"
    }
  }
]

One proposal would be to update import single string properties to imports array of string properties. This would enable the following while colocating the necessary import information together with the requiring implementation details:

"validators": [
  {
    "custom": {
      "imports": [
        "github.com/hashicorp/terraform-plugin-framework-validators/stringvalidator",
        "regexp"
      ],
      "schema_definition": "stringvalidator.RegexMatches(regexp.MustCompile(/* ... */), \"...\")"
    }
  }
]

Another potentially less desirable proposal would be to support a new schema level property such as additional_imports array of strings, which generators could additionally check.

[bflad]

I think even if we did introduce some extremely common use case validators as their own properties, e.g.

"validators": [
  {
    "regex": {
      "pattern": "^i-[0-9a-f]{8}$",
      "message": "must begin with i- and have 8 lowercase hexadecimal characters" // optional
    }
  }
]

There would still be cases that provider developers could need to have multiple imports with custom validators, etc.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.