Closed bflad closed 1 year ago
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.
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.
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 theregexp
import.One proposal would be to update
import
single string properties toimports
array of string properties. This would enable the following while colocating the necessary import information together with the requiring implementation details: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.